View mode: basic / threaded / horizontal-split · Log in · Help
August 29, 2007
Re: class extensions
Robert Fraser Wrote:

> Michael Deardeuff Wrote:
> 
> > I am very excited about the future of D. Walter's and Andrei's talk at the conference was awesome.
> > 
> > However, there are still a few quirks to get out:
> > This is regarding slide 9 of the presentation.
> > 
> > I noticed that most people at the conference liked the idea of extending library classes, but were not to pleased with the interchangability of 
> > ---
> > foo(a, args)
> > ---
> > and
> > ---
> > a.foo(args)
> > ---
> > like the arrays have.
> 
> Really? I got the feeling it was very well-received. I like the idea quite a bit, not necessarily just for class extensions (I think it might encourage a lower degree of encapsulation, although if the fields are package-private this might be mitigated by adding class extensions in other modules in the same package), but for primitive types.
> 
> > 
> > I have a suggestion: class extensions kindof like C#'s partial classes
> > ----
> > class A {...}
> > ...
> > extension class A {
> >    void foo(args) {...}
> > }
> > ...
> > a.foo(args);
> > ----
> > (maybe the syntax could be "class extension A" or "extension A"...)
> > 
> > In this way class extensions are clearly marked and the syntax is consistent.
> > 
> > It would be easy to add interfaces to the library class:
> > 
> > extension A : Visitable {
> >    void accept(Visitor v) {...}
> > }
> > 
> > Just an idea for you guys, Walter, Andrei, and the community.
> > 
> > --Michael Deardeuff
> > 
> 
> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.

Excellent point. Blast.
I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
And, of course,  I'm in here for myself. j/k. But not really.

--Michael Deardeuff
August 29, 2007
Re: class extensions
Michael Deardeuff wrote:
> Robert Fraser Wrote:
[snip]
>> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.
> 
> Excellent point. Blast.
> I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
> I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
> And, of course,  I'm in here for myself. j/k. But not really.
> 
> --Michael Deardeuff

Yeah, the proposed extensions raised all kinds of red flags for me at 
the conference.

Bluntly, it felt like the notion of "structured programming" was being 
tossed out in favor of "slapdash programming" ... a brand new paradigm 
to go along with the other(s) being adopted :)
August 29, 2007
Re: class extensions
kris wrote:
> Michael Deardeuff wrote:
>> Robert Fraser Wrote:
> [snip]
>>> I proposed this a while ago, and I agree this would be a good idea. 
>>> However, the more I think about it, the more I realize that in a 
>>> native-compiled language we're talking vtable problems - how do we 
>>> know when the vtable is finished? If partials are cross-module, it 
>>> would require recompilation of every involved module, and just be 
>>> generally problematic.
>>
>> Excellent point. Blast.
>> I think it still _is_ a good idea if you scrap the inheritance/vtable 
>> problem and only allow extension classes to use the syntax "a.foo(...);"
>> I guess what I'm getting at is, I don't like the prospect of working 
>> with code that in one line is "foo(a, ...);" and the next 
>> "a.foo(...);" With the extension class bit it makes it clear that only 
>> methods meant as a class extension can (and must) use the "a.foo();" 
>> syntax, which I prefer.
>> And, of course,  I'm in here for myself. j/k. But not really.
>>
>> --Michael Deardeuff
> 
> Yeah, the proposed extensions raised all kinds of red flags for me at 
> the conference.
> 
> Bluntly, it felt like the notion of "structured programming" was being 
> tossed out in favor of "slapdash programming" ... a brand new paradigm 
> to go along with the other(s) being adopted :)

It's pretty much the same deal as with property syntax.  A lot of folks 
think the use of property syntax with a function should need to be 
enabled explicilty to avoid nonsense like writefln = 5;

But Walter seems to think it's ok the way it is.  Given that, I can 
definitely see how he'd think making a.foo uniformly interchangable with 
foo(a) makes sense.  I guess with property syntax and this combined 
we'll have
   "a.value" == "value(a)" == "value = a"

Which seems pretty weird to me.

--bb
August 29, 2007
Re: class extensions
Bill Baxter wrote:
> But Walter seems to think it's ok the way it is.  Given that, I can
> definitely see how he'd think making a.foo uniformly interchangable with
> foo(a) makes sense.  I guess with property syntax and this combined
> we'll have
>    "a.value" == "value(a)" == "value = a"
> 
> Which seems pretty weird to me.
> 
> --bb

I actually welcome this as a straightforward way to enable coders to
write out what they mean.
Of course, it can be abused for stuff like writefln="whee", but in many
cases, abusability is related to the power/expressiveness of a feature -
if you can use it to express more, it follows that you can also use it
to express more garbage; however, that doesn't mean you have to.
--downs
August 30, 2007
Re: class extensions
kris wrote:
> 
> Yeah, the proposed extensions raised all kinds of red flags for me at 
> the conference.
> 
> Bluntly, it felt like the notion of "structured programming" was being 
> tossed out in favor of "slapdash programming" ... a brand new paradigm 
> to go along with the other(s) being adopted :)

What are the objections to this? Are there technical pitfalls?

I liked to idea very much. It gives a flexible way of object-oriented / 
object-based programming similar to how I often see it implemented in C. 
Plus one can achieve a very nice syntactic sugar for call chaining, 
which is a great benefit I think. I thought this syntax for arrays is 
generally appreciated, so why not extend it for other types?
August 30, 2007
Re: class extensions
Lutger wrote:
> kris wrote:
>>
>> Yeah, the proposed extensions raised all kinds of red flags for me at 
>> the conference.
>>
>> Bluntly, it felt like the notion of "structured programming" was being 
>> tossed out in favor of "slapdash programming" ... a brand new paradigm 
>> to go along with the other(s) being adopted :)
> 
> What are the objections to this? Are there technical pitfalls?

Technical? Since when did that become important? ;)

I belong to the "just because you can doesn't mean you should" camp, and 
feel that perhaps a more holistic view should be taken here? Just don't 
see this specific idiom as being particularly beneficial, without adding 
detrimental side-effect that I'll briefly touch on in a moment (it never 
really had significant value with arrays either, other than perhaps as a 
means to confuse non-experts O_+)

> I liked to idea very much. It gives a flexible way of object-oriented / 
> object-based programming similar to how I often see it implemented in C. 

And it potentially introduces additional namespace issues, hijacking 
issues, and compilation errors for large and/or long-term software 
development projects. The commercial-development space is where D ought 
to target, if it's to rise well above being just another enthusiasts 
playground :p

A conservative approach would remove the existing idiom with arrays, 
rather than propagate it, and address concerns instead by perhaps 
looking at alternate approaches for supporting 'properties' (C# for 
example). Are you thinking this makes a good solution for 'properties' 
in general? As has been discussed recently?

> Plus one can achieve a very nice syntactic sugar for call chaining, 

D provides that already, no? Tango supports call-chaining extensively.

> which is a great benefit I think. I thought this syntax for arrays is 
> generally appreciated, so why not extend it for other types?

Just because some folks apparently like it, and are vocal about it, 
doesn't necessarily make it "generally appreciated"? That's a problem 
with newsgroups and forums though ... it's perhaps easy to get a skewed 
perspective?

As for extending to other types, that's cool! I just feel this 
particular idiom potentially builds smoldering fires larger than the 
one(s) it is attempting to extinguish (or perhaps it's not even trying 
to resolve anything?). If that is the case it is hardly an adequate 
resolution, and will simply return to bite D in the buttocks.

As such, I suspect alternatives should be given great consideration (or 
/greater/ consideration) and the relative trade-offs should be weighed 
appropriately. Yourself, and others, may feel that's not necessary or 
has been adequately performed already? I don't feel that way, and it's 
not the impression I got from the conference :-D

(parts of this are written somewhat tongue-in-cheek, as there's only so 
much one can achieve via this medium. Please just take it as my opinion, 
and nothing more)
August 30, 2007
Re: class extensions
"kris" <foo@bar.com> wrote in message news:fb5742$nek$1@digitalmars.com...
>
>> Plus one can achieve a very nice syntactic sugar for call chaining,
>
> D provides that already, no? Tango supports call-chaining extensively.

I think by call-chaining he was referring to cases such as 
join(reverse(split(toUpper(str)))) vs. str.toUpper.split.reverse.join(). 
The latter is arguably much more readable than the former.
August 30, 2007
Re: class extensions
Jarrett Billingsley wrote:
> "kris" <foo@bar.com> wrote in message news:fb5742$nek$1@digitalmars.com...
>>> Plus one can achieve a very nice syntactic sugar for call chaining,
>> D provides that already, no? Tango supports call-chaining extensively.
> 
> I think by call-chaining he was referring to cases such as 
> join(reverse(split(toUpper(str)))) vs. str.toUpper.split.reverse.join(). 
> The latter is arguably much more readable than the former. 

Had completely missed that, Jarret. Thanks, and fair point
August 30, 2007
Re: class extensions
Bill Baxter wrote:
> [...]
> But Walter seems to think it's ok the way it is.  Given that, I can 
> definitely see how he'd think making a.foo uniformly interchangable with 
> foo(a) makes sense.  I guess with property syntax and this combined 
> we'll have
>    "a.value" == "value(a)" == "value = a"

Oooh it looks like this would be possible to write:

3.times = (int a) { Stdout(a.toUtf8).newline; }

...fun! :D
August 30, 2007
Re: class extensions
kris wrote:

> Lutger wrote:
>> kris wrote:
>>>
>>> Yeah, the proposed extensions raised all kinds of red flags for me at
>>> the conference.
>>>
>>> Bluntly, it felt like the notion of "structured programming" was being
>>> tossed out in favor of "slapdash programming" ... a brand new paradigm
>>> to go along with the other(s) being adopted :)
>> 
>> I liked to idea very much. It gives a flexible way of object-oriented /
>> object-based programming similar to how I often see it implemented in C.
> 
> And it potentially introduces additional namespace issues, hijacking
> issues, and compilation errors for large and/or long-term software
> development projects. The commercial-development space is where D ought
> to target, if it's to rise well above being just another enthusiasts
> playground :p

It will also be directly detrimental to maintainability when used for user
defined types, as you no longer will be able to decide where a function is
implemented by only looking at the call site (given inheritance and
polymorphism this can in cases be difficult enough, but at least you have a
type hierarchy to look to).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home