> No, you're right. It's caused by "clowntown development". > Nice term BTW. But GC tends to make this kind of > f clowntown development easier because you don't have to > keep track of your data (as much).
This is a classic conundrum I think. If you use a harder language, the skill level of the developer tends to go up when you are looking for developers that know the language. However, taking a clowntown developer and giving him a harder tool to use is probably not going to improve things. It's likely to get a lot worse.
I think what it comes down to is getting good people giving them the right tools for the job. The problem I see is easy languages are chosen with the idea that you can get less-skilled developers.
> Whenever the last > reference goes null or out of scope, then the data will > remove itself (hopefully). I just think if there was more > enforcement and planning on what data these functions can > use and what objects they can create and use, then there > would be less problems. But this is the whole reason > behind GC. To not have to track your data. This may be a > personal opinion, but I find that GC and the calling out > the back issue (along with normal interfaces to some > extent) are diametrically opposed. One is implicit, the > other is explicit.
You are on to something but I don't think you realize it. The problem people run into with GC is that they think they can just forget about what happens to their Objects when they are done with them. That's not the case. You must code to ensure they are released. The most effective way to do this is to limit scope as much as possible which actually improves the code in general.
> I am not saying removing GC is the answer either because > C++ has the same problem. The solution is to have a back > interface so that the application can let it only use > functionality that is considered "safe", whatever that may > mean in your project. I have seen no language that > supports this of yet, but I have not seen all languages. > I doubt it would be popular because you would need the > e IDE or some tool to help you out and unless there is > some kind of code hiding feature, I think it would be > messy and cumbersome.
I was thinking that a syntax that allowed Objects to appear to have different interfaces from different contexts would be nice. There are ways to produce this though design patterns but a language supported feature might address this 'call-out-the-back' issue and more.
> Imagine that you're implementing an interface and you > can't use the "new" keyword or call any functions unless > they are part of the standard library (considered safe) or > from another interface or supplied by the application? > Note too that the GC is irrelevant because all your > r resources must be externally and explicitely supplied to > make sure you don't cause havoc and use safe > functionality.
I don't understand why this would be incompatible with GC. Unless I misunderstand you, I do this a lot in Java now.
> No way that this would fly now that GC is > so popular. Manual management of resources is not "IN" > anymore. But there's no doubt that unbridled method calls > and use of "new" leads to coupling.
I'm kind of confused by what you are saying here. In Java, at least, new is the only way to allocate Objects. Constructors don't need to be public, though.
GC is also winning because it's allowing Java Objects to be allocated and deallocated more efficiently (faster) than in C. Because the GC can manage the heap, it can ensure that Objects are always allocated in contiguous memory.
"Think of the interface as being the top of the box. The damage is done by the thread of control coming out of the bottom of the box — nothing to do with the “interface”". If Diggins uses the word "interface" in the sense it usually has in the context of OOP, then this statement can only mean: "The interface is correct (as far as it goes), but the implementation is screwed up". Nobody will argue about that, and it's hardly a surprising revelation.
What I am worrying about, though, is that Diggins is *not* using "interface" in the sense everybody else is using it. It even seems that he doesn't have a clue what he's talking about. The statement "The call b.h() in class Foo is an important part of its behaviour — and therefore must be considered as part of its interface." is complete nonsense. The Braun tube inside my monitor is definitely an important part of its behaviour, and it's definitely not part of its interface. And if the monitor were broken because the wires that are connecting it with other modules have been wired incorrectly (1), this still would be an implementation error and not a "back interface" problem, even if I agreed with calling those wires a "back interface".
In the code example (what language is that supposed to be, btw?), why should the "invariant" on a private instance variable be regarded as part of the public interface of the class Foo? Moreover, the code doesn't explain how the Bar object b got into the Foo object and how b got a reference to the latter. Apart from that, if a language allows to specify class invariants (or any other sort of contract) as part of its public interface but the contract is violated at runtime, this still is a pure implementation problem. There's nothing to be learned from pretending otherwise. Blogs like Diggins' only prove once more the still widespread ignorance of object-oriented concepts in the programming community.
(1) wired incorrectly inside the box, in analogy to the code example; it would be a different matter if the wire were simply plugged into the wrong socket. This would be more of an interface problem, but it's not obvious why we should call it "back interface".
The problem isn't that the programmer made a mistake in the implementation of the interface (or the order of calls). It's that the object requiring the interface cannot be assured that when it calls this interface, that the interface doesn't do something malicious or erroneous, thus making the object itself incorrect by proxy.
That is wrong. If all public methods are implemented in a way that guarantees the contract (in that case, by not interrupting atomic operations), and if the language guarantees that the nonpublic parts of any class cannot be accessed from outside (in Java, the programmer of course also must care about protected parts of a nonfinal class), then the other class cannot maliciously break the contract, whatever it does.
Matters would be different if the operations of class Foo were *relying on the contract of the Bar class*, for example if it used a function that promises to multiply by two. If Bar violates that contract, then Foo will also violate its contract. In that case, there would be an implementation bug in Bar that is propagated to all of its clients. Still, nothing magic about that.
> > You are on to something but I don't think you realize it. > The problem people run into with GC is that they think > k they can just forget about what happens to their Objects > when they are done with them. That's not the case. You > must code to ensure they are released. The most effective > way to do this is to limit scope as much as possible which > actually improves the code in general.
I realized it. You just worded it better ;) I like your comment on scope too. That's very important. I don't see this mentioned as often as it should.
> > > Imagine that you're implementing an interface and you > > can't use the "new" keyword or call any functions > unless > > they are part of the standard library (considered safe) > or > > from another interface or supplied by the application? > > Note too that the GC is irrelevant because all your > > r resources must be externally and explicitely supplied > to > > make sure you don't cause havoc and use safe > > functionality. > > I don't understand why this would be incompatible with GC. > Unless I misunderstand you, I do this a lot in Java now.
I just mean that GC is not used at all (not that it's incompatible exactly). Externally to the interface is a different story though. > > > No way that this would fly now that GC is > > so popular. Manual management of resources is not "IN" > > anymore. But there's no doubt that unbridled method > calls > > and use of "new" leads to coupling. > > I'm kind of confused by what you are saying here. In > Java, at least, new is the only way to allocate Objects. > Constructors don't need to be public, though.
Yeah, but letting an interface use "new" means that it can allocate any object it wishes. Objects that don't have any restrictions on them. If this object could only access "things" that are inside the interface, then fine. But there is no such restriction in most languages. Not in Java or C++ anyhow. This is call out the back issue. What does the interface need to get the job done and how do you make sure it doesn't affect "things" that it shouldn't.
> > GC is also winning because it's allowing Java Objects to > be allocated and deallocated more efficiently (faster) > than in C. Because the GC can manage the heap, it can > ensure that Objects are always allocated in contiguous > memory.
No. It may be faster in some cases, but it's far less efficient. Efficency is calculated by its speed and how much memory it uses. Not by speed alone as you incorrectly mention. GC with its collosal memory usage still has a long way to go before it can catch up to C as far as efficiency goes.
> > > Note too that the GC is irrelevant because all your > > > r resources must be externally and explicitely > supplied > > to > > > make sure you don't cause havoc and use safe > > > functionality. > > > > I don't understand why this would be incompatible with > GC. > > Unless I misunderstand you, I do this a lot in Java > now. > > I just mean that GC is not used at all (not that it's > incompatible exactly). Externally to the interface is a > different story though.
I'm still not following you. How is GC not used?
> > > No way that this would fly now that GC is > > > so popular. Manual management of resources is not > "IN" > > > anymore. But there's no doubt that unbridled method > > calls > > > and use of "new" leads to coupling. > > > > I'm kind of confused by what you are saying here. In > > Java, at least, new is the only way to allocate > Objects. > > Constructors don't need to be public, though. > > Yeah, but letting an interface use "new" means that it can > allocate any object it wishes. Objects that don't have > any restrictions on them. If this object could only > access "things" that are inside the interface, then fine. > But there is no such restriction in most languages. Not > t in Java or C++ anyhow. This is call out the back issue. > What does the interface need to get the job done and how > w do you make sure it doesn't affect "things" that it > shouldn't.
But who says you must supply a public constructor?
> > GC is also winning because it's allowing Java Objects > to > > be allocated and deallocated more efficiently (faster) > > than in C. Because the GC can manage the heap, it can > > ensure that Objects are always allocated in contiguous > > memory. > > No. It may be faster in some cases, but it's far less > efficient. Efficency is calculated by its speed and how > much memory it uses.
Sorry but that's incorrect. Efficiency can be calculated in terms of memory OR speed. I was qualifying that in that context, it was in regards to speed.
> Not by speed alone as you > incorrectly mention. GC with its collosal memory usage > still has a long way to go before it can catch up to C as > far as efficiency goes.
I don't see how GC creates more memory usage other than the collectors overhead and that is not that significant in my experience.
Yeah, but letting an interface use "new" means that it can allocate any object it wishes. Objects that don't have any restrictions on them. If this object could only access "things" that are inside the interface, then fine. But there is no such restriction in most languages. Not in Java or C++ anyhow. This is call out the back issue.
Since when are there "things" "inside an interface"? Once again, you are mixing up interface and implementation.
piglet: It's obvious that an unimplemented interface can't NEED or USE anything. With all due respect, I hope you're not being contentious on purpose.
JW: First about the GC, we'll have to agree to diasgree. I've seen first hand that GC's on Java are slow and bloated. Don't know about SmallTalk though.
About the rest, here's the main point. The IMPLEMENTATION (just to be clear) of an interface, if it is free to access parts of your software (whether by "new" or obtaining a reference to an object somehow), then this creates coupling. Basically, it means that you cannot simply replace the implementation of the interface by swapping the old code out and the new code in. In order to replace the implementation of the interface (IOTI from now on), you would have to also change parts of your application. Note that I'm defining "application" as the software without the IOTI.
The IOTI needs to be independant from the rest of the application. Any deviation from this means that your interface is useless. You cannot replace the implementation without also modifying the rest of the application, so what's the point in using an interface in the first place?
This is what I was saying earlier that you need to make sure the IOTH can only use resources given to it if it needs to interact with the rest of the application. It shouldn't be allowed to do this of its own accord. That's what I meant that GC is not used. All resources are supplied and controlled by external sources. Again, these resources should be provided via interfaces: back-interfaces.
Get it? But there's no such restriction in OOP languages.
> JW: First about the GC, we'll have to agree to diasgree. > I've seen first hand that GC's on Java are slow and > d bloated. Don't know about SmallTalk though.
It's not the GC that's slow (well, 1.1 and 1.2 were kind of slow and 1.3 wasn't so hot) it's the code that is bad. I wrote a commandline utilities in Java that can search fairly large files about as fast as grep but with regular expressions. I didn't even optimize it; it's a naive implementation.
Isn't saying that because you've seen a few Java applications with poor performance that all have poor performance a little like saying you know some people of a specific ethnicity or nationality that were rude an obnoxious therefore all people of that classification must be?
I na Java application, you can constrain the amount of memory that it's allowed to use be in the kilobyte range. If your app doesn't require more memory than that at any single moment, it will work just fine. People don't generally do this because memory is generally considered less important than time.
I don't want to be presumptive but it seems to me that you are fairly misinformed about garbage collection. Some of the things you have said are very outdated and others are outright wrong. If you really want to have an informed opinion on this I would suggest learning more about it. IBM provides a good amount of documents about GC technology. It's also changing all the time. For example, the next verison of Java will be able to allocate Objects on the stack automatically without any change to syntax. There are a myriad of GC alorithms. Some are the bubble sorts of GC (like early JVMs used) and others are highly sophisticated.
> JW: First about the GC, we'll have to agree to diasgree. > I've seen first hand that GC's on Java are slow and > d bloated. Don't know about SmallTalk though.
Actually I will conceed that JVMs struggle with GC on Windows. The problem appears (to me) to be that windows pages memory silently and in the case of a JVM, a lot of what it pages is garbage. This causes problems in an app with high memory usage because when the GC runs, it's required to page in garbage in order to release it. Even worse, it appears to page the reclaimed memory so that when it wants to use it again, it pages in empty memory from disk. This problem doesn't seem to manifest itself in Solaris which makes me think that the VM has more visibility into what the OS is doing and helps to avoid this scenario.
> This is what I was saying earlier that you need to make > sure the IOTH can only use resources given to it if it > needs to interact with the rest of the application. It > shouldn't be allowed to do this of its own accord. That's > what I meant that GC is not used. All resources are > supplied and controlled by external sources.
This is orthoganal to garbage collection. What I don't understand is what relevance GC has to your point.
> Again, these > resources should be provided via interfaces: > back-interfaces.
But there is a solution to this that is used now. The resources are retrieved through another interface. Actually I prefer not to return the interface at all but rather make the resource users pass me a handler. This allows for more reliable handling of resources. So the IOTI talks to another abstract interface to get it's resources. This is how you avoid coupling the IOTI. Now, that the IOTI uses this other interface may not be apparent. Documentation should provide the detail on this. If there is a language idiom that could be introduced that would deal with this, that's fine, but I see little point unless it's something that the machine can understand and use.
The IMPLEMENTATION (just to be clear) of an interface, if it is free to access parts of your software (whether by "new" or obtaining a reference to an object somehow), then this creates coupling.
More or less agreed. Avoiding unnecessary coupling is a well-known OO design principle, but it can't be enforced by the compiler or any language tricks. The programmer who is implementing an interface is free to write whatever stupid, crappy code he wants as long as he implements the interface.
Btw, what exactly do you mean by "free to access parts of your software"? "Access" is always defined by public interfaces. If each class in the application is designed to expose itself only to the extent that its integrity is not compromised, then accessing it won't break anything. Incidentally, this is almost the definition of correct OO design.
Basically, it means that you cannot simply replace the implementation of the interface by swapping the old code out and the new code in. In order to replace the implementation of the interface (IOTI from now on), you would have to also change parts of your application.
I don't know why this should be a problem as long as the implementation fulfills the contract.
The IOTI needs to be independant from the rest of the application. Your system would then be a set of mutually independent components? Once again, modular encapsulation and weak coupling are sound design principles but you'd still want some interaction between your components, wouldn't you? This interaction should be explicitly defined by the interfaces and be governed by contracts.
Any deviation from this means that your interface is useless. You cannot replace the implementation without also modifying the rest of the application, so what's the point in using an interface in the first place?
If the design is sound, then different components can evolve independently of each other even if they interact with each other via interfaces.
Flat View: This topic has 25 replies
on 2 pages
[
«
|
12
]
Previous Topic
