"Sean L. Palmer" wrote:

> In addendum I'd like to point out that I don't want methods declared outside the original declaration to be able to access private methods or data (maybe only one definition linked in could not have the "extend" keyword, all others would have to have it.).
>
> So you could only decorate classes with methods built on their original public interface.  Just convenient syntax sugar for a normal function call taking a reference to an object of the type as a hidden "this" parameter, just grouped together and placed into the scope of the class.
>
> Is this even remotely technically feasible?  I wonder how one would import them;  maybe they would just become part of the class symbol table if the file imports a module containing the (public) extended class definition.  Or declare the extention in the current module somewhere.

I like this idea!  I would also note, though, that any functions you define this way could never be virtual.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:acc8o2$1lok$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:acbltp$14nt$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> > > It is a good idea.
> >
> > Perhaps there is a way to extend use of this to solve the I/O formatting problem as well.  Just have the formatting code call each variable's to string method. (If a variable was already a string, the method would
> return
> > the same string.).  Then, if someone wanted some special formatting, he could override the tostring method.  It also handles the formatting
> problems
> > of complex variables automatically and very nicely also.
>
> The problem with that approach is there's no vptr for the basic types, so
no
> way to override it.

Ahhh!  Another beautiful theory, spoiled by an ugly fact  :-(

--
 - Stephen Fuld
   e-mail address disguised to prevent spam