defender method syntax considered harmful
Per Bothner
per at bothner.com
Thu Sep 30 12:30:48 PDT 2010
On 09/29/2010 06:23 PM, Alex Buckley wrote:
> On 9/29/2010 5:41 PM, Per Bothner wrote:
>> I don't think "conceivable" is good enough. We need examples.
>> E.g. we might want to add a new method to Collection. Perhaps Set and
>> List could use the same default implementation, while Map uses a different
>> default. Then somebody defines a class that implements both Set and List.
>> We want that to be OK, since they use the same default.
>>
>> The problem is I can't think where that might make sense. Presumably
>> if you add a method to Collection, you need to add a default for it.
>
> (I'm confused as to why you say "We want that to be OK" in one sentence
> but then can't think of where it might make sense in the next.)
I was try to paraphrase/understand your concern - but also saying
I'm not convinced it's an issue.
> Language design is led by principle, not example.
Language design must be led by example *and* principle.
There is no point in adding a feature if no one can come up with
an example to make use for it. Especially if it something that
can be added later. (An exception is if a feature makes
the language more regular or simpler: E.g. Concepts A and B are in a
language because they're useful. We still have to consider their
interaction even we don't have an example for using them together.)
>It should be clear
> that, depending on a) the dominance of a hyperinterface (j.u.Collection
> is rather dominant in j.u), b) the shape of the interface hierarchy, and
> c) the availability of sensible defaults, there is the possibility of
> common (i.e. unique) defaults across a class's superinterfaces.
You say "possibility", but I can't think of an example that makes
sense in terms of sane object-oriented design: If two interfaces
share the same default it's because the are both subinterfaces
of the same hyperinterface, which is where the default belongs.
--
--Per Bothner
per at bothner.com http://per.bothner.com/
More information about the lambda-dev
mailing list