abstract static methods (again)
in [Java Help]
|
Prev: Java work from home. Remote (telecommuting) jobs in Java.
Next: Zip question: Where are all the extra characters coming fromupon unzipping?
From: Arved Sandstrom on 21 Oct 2009 18:00 Andreas Leitgeb wrote: > Arved Sandstrom <dcest61(a)hotmail.com> wrote: >> Maybe it's just me, but if I want an abstract class to require specific >> constructor signatures of its subclasses, I give that abstract base >> class that constructor. :-) > > You may of course do that, but that doesn't put any > constructor *requirements* upon the subclasses. > I was way too tired when I wrote that. :-) AHS
From: Steven Simpson on 22 Oct 2009 04:53 Tomas Mikula wrote: > On Wed, 21 Oct 2009 18:05:33 +0100, Steven Simpson wrote: > >> Now express two constraints on the type provided to MyClass: >> >> class MyClass<V extends Vector<V> & V extends static Zero<V>> { >> > [...] But you need to add a new syntax, namely the > '&' in the generic parameters. > Well, the & already exists, but I extrapolated the syntax in an unlikely way. It probably should have been more like this: class MyClass<V extends Vector<V> & static Zero<V>> { -- ss at comp dot lancs dot ac dot uk
From: Arne Vajhøj on 25 Oct 2009 13:04 Andreas Leitgeb wrote: > Tom Anderson <twic(a)urchin.earth.li> wrote: >>> This whole topic is inspired by dynamic loading of classes. >> This problem was solved in the golden age of the Patternists. The solution >> is that you don't load Entertainers, you load EntertainerAgencies. > > Oh, nice! Yet another extra indirection! > Wasn't there some "computer law" that said, that any problem can be > addressed (but not necessarily solved) by adding another level of > indirection? Yep. I can not find the source, but it is something like: "There is no coding problem that can not be solved nicely by adding another abstraction layer and no performance problem that can not be solved by removing an abstraction layer." It is not true, but it definitely has a good point. Arne
From: Arved Sandstrom on 25 Oct 2009 13:29 Arne Vajh�j wrote: > Andreas Leitgeb wrote: >> Tom Anderson <twic(a)urchin.earth.li> wrote: >>>> This whole topic is inspired by dynamic loading of classes. >>> This problem was solved in the golden age of the Patternists. The >>> solution is that you don't load Entertainers, you load >>> EntertainerAgencies. >> >> Oh, nice! Yet another extra indirection! >> Wasn't there some "computer law" that said, that any problem can be >> addressed (but not necessarily solved) by adding another level of >> indirection? > > Yep. > > I can not find the source, but it is something like: > > "There is no coding problem that can not be solved nicely > by adding another abstraction layer and no performance problem > that can not be solved by removing an abstraction layer." > > It is not true, but it definitely has a good point. > > Arne The point being, too much of a good thing is bad. A very basic abstraction layer is a single function/method/procedure: apart from the code re-use issue we typically also elect to use methods so as to hide implementation details. Used judiciously methods are great, but when overused you tend to stop understanding the code. Performance I am less worried about. I judge abstractions by their impact on maintainability of code during design, implementation and production use. If their positives don't outweigh the negatives then why are they there? AHS
From: Tomas Mikula on 28 Oct 2009 16:25
I have implemented a subset of the proposal with the @ImplementsStatic annotation. Only later I found Stefan Schulz's blog entry where he proposed the same. So his code will probably be similar, but I haven't found it anywhere. Anyway, I created a project http://code.google.com/p/implementsstatic/ where you can find the code and brief user's guide and examples. |