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: Tom Anderson on 19 Oct 2009 15:19 On Mon, 19 Oct 2009, Eric Sosman wrote: > Andreas Leitgeb wrote: > >> On second thought: If the Entertainers were designed to be dynamically >> loaded by name, then Comedians just wouldn't have any chance of a >> individual default joke. They could offer their Joke- constructor, but >> unless they also offered a no-args one, they just wouldn't ever be >> successfully engaged. > > But I admit that my familiarity with frameworks of this kind is > slight. Perhaps they're just not suited for classes whose instances > lack obvious defaults. (Maybe they're only good for singletons?) They have a mechanism for configuring objects as well as creating them. I use one which for each object you want to create, there's a property file, which looks like: $class=com.sosman.strawman.Comedian joke=A compiler, a linker, and an editor walk into a bar ... Which is translated by the reflective machinery into calls like: Class cl = Class.forName("com.sosman.strawman.Comedian"); Object obj = cl.newInstance(); cl.getMethod("setJoke", String.class).invoke(obj, "A compiler, a linker, and an editor walk into a bar ..."); With some more stuff to deal with properties that aren't strings. It's not pretty, but it quite often works. It might be better if the framework tried to find a constructor which would take the specified parameters, but it's not obvious how you'd do that. However, i don't see how Tomas's proposal would help. tom -- Civis Britannicus sum.
From: Tom Anderson on 19 Oct 2009 16:05 On Mon, 19 Oct 2009, Tomas Mikula wrote: > Now I present two examples where it would be useful. > > (1) Eliminate or reduce the use of reflection in serialization frameworks. This example isn't actually about your proposal, it's about ... > a new magic class Implementation<T> .... so i'm going to ignore it. > (2) The second use case is with generics, but would require reified > generics (which I hope will appear in some future version of Java). > > Suppose you have an abstract class Vector which represents a vector in a > vector space (don't confuse with java.util.Vector) and a few > implementations, like Vector2D and Vector3D. [...] Now let's have a > generic class that will use vectors and do operations on them, but > doesn't really care about their actual dimension. So it will work with > abstract type Vector. But for some operations it may be necessary to > obtain the zero vector, without explicitely knowing the actual type of > vector. This is a good use case. But i suspect it can be done with java as it stands now - rather than reified generics, you factor out a Type Object, as the patternists call it. Vectors can tell you their type object, and the type object can give you a zero. Like this, for instance: http://urchin.earth.li/~twic/Code/MutuallyRecursiveGenerics/Vector.java Now, i should say that that is some fairly bonkers generics (in fact, i think i can now claim Double Wizard status at generics). It took me a good while to get the types straight, and even now, the declarations are of a mind-searing eldritch uncanniness verging on the Lovecraftian. But what we need to fix this is some more concise generics syntax, not some semantically befuddled new kind of method inheritance. I can't say exactly what, though. tom -- Civis Britannicus sum.
From: Tom Anderson on 19 Oct 2009 16:14 On Mon, 19 Oct 2009, Andreas Leitgeb wrote: > Eric Sosman <Eric.Sosman(a)sun.com> wrote: >> Andreas Leitgeb wrote: >>> I still see some merit in being able to enforce that any concrete >>> class implementing some thusly declared interface had to offer some >>> particular c'tor, as a means to help developers of such classes to >>> not forget about it. > >> Here's my objection: Suppose there's an Entertainer interface >> (or abstract class) and ... >> ... >> Okay, it might make sense for the class of Comedians to have a >> default stale Joke (a faithful model of reality, perhaps), ... > :-) >> ... >> The author of Entertainer, who knew nothing about the wants and needs >> of those who would come later, ... > > Thanks for the entertaining example, but I think it's beside the point. > This type of argument "it's bad for this exemplary usecase, so it must > be bad for all usecases" is obviously flawed. (or was a joke, itself) > > On second thought: If the Entertainers were designed to be dynamically > loaded by name, then Comedians just wouldn't have any chance of a individual > default joke. They could offer their Joke- constructor, but unless they > also offered a no-args one, they just wouldn't ever be successfully engaged. > > This whole topic is inspired by dynamic loading of classes. Otherwise, there > wouldn't really be any use for dictating constructors at all. Dynamic loading > of classes seems to me of increasing importance with all those AppServers, > J2EE, ... Demanding the default-constructor (or even with a specific set > of arguments) for those classes imposes no new restriction, just formalizes > the restrictions that were already imposed by documentation and use. This problem was solved in the golden age of the Patternists. The solution is that you don't load Entertainers, you load EntertainerAgencies. public interface EntertainerAgency { public Entertainer hire(); } String agencyName = loadFromWherever(); EntertainerAgency agency = (EntertainerAgency)Class.forName(agencyName).newInstance(); Entertainer e = agency.hire(); The question of some putative Entertainer constructor goes away. You do have the question of the EntertainerAgency constructor, but this is much less pressing. If it really worries you, use a EntertainerAgencyFactory. Before you ask, yes, it's factories all the way down. Until you reach the turtles. tom -- Ideas are bulletproof. -- V
From: Tom Anderson on 19 Oct 2009 16:15 On Mon, 19 Oct 2009, Andreas Leitgeb wrote: > Marcin Rze?nicki <marcin.rzeznicki(a)gmail.com> wrote: >> On 19 Pa?, 17:32, Arved Sandstrom <dces...(a)hotmail.com> wrote: >>> Marcin Rze?nicki wrote: >>>> On 19 Pa?, 16:13, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> >>>> wrote: >>>>> I still see some merit in being able to enforce that any concrete >>>>> class implementing some thusly declared interface had to offer some >>>>> particular c'tor, as a means to help developers of such classes to >>>>> not forget about it. >>>> Yep, this is not bad. >>> I prefer the annotations-based method such as described here: >>> http://www.javaspecialists.eu/archive/Issue167.html >> Nice, it wins :-) > > Indeed nice, but what would be the extra effort to create e.g. a > @StringArgConstructor annotation and its processing? And then also > a @StringStringArgConstructor and a @StringMyFooIntArgConstructor, ... Or maybe just a @DefinedConstructor annotation that takes an array of classes as a parameter. tom -- Ideas are bulletproof. -- V
From: Tomas Mikula on 19 Oct 2009 17:50
On Mon, 19 Oct 2009 20:19:51 +0100, Tom Anderson wrote: > On Mon, 19 Oct 2009, Eric Sosman wrote: > >> Andreas Leitgeb wrote: >> >>> On second thought: If the Entertainers were designed to be dynamically >>> loaded by name, then Comedians just wouldn't have any chance of a >>> individual default joke. They could offer their Joke- constructor, >>> but unless they also offered a no-args one, they just wouldn't ever be >>> successfully engaged. >> >> But I admit that my familiarity with frameworks of this kind is >> slight. Perhaps they're just not suited for classes whose instances >> lack obvious defaults. (Maybe they're only good for singletons?) > > They have a mechanism for configuring objects as well as creating them. > I use one which for each object you want to create, there's a property > file, which looks like: > > $class=com.sosman.strawman.Comedian > joke=A compiler, a linker, and an editor walk into a bar ... > > Which is translated by the reflective machinery into calls like: > > Class cl = Class.forName("com.sosman.strawman.Comedian"); Object obj = > cl.newInstance(); > cl.getMethod("setJoke", String.class).invoke(obj, "A compiler, a > linker, and an editor walk into a bar ..."); > > With some more stuff to deal with properties that aren't strings. It's > not pretty, but it quite often works. > > It might be better if the framework tried to find a constructor which > would take the specified parameters, but it's not obvious how you'd do > that. However, i don't see how Tomas's proposal would help. The use of my proposal here would be to enforce a constructor or a static creator method that would create an initialized object from ObjectInputStream/JAXBElement/javolution.xml.XMLFormat.InputElement /... |