Re: define methods apart
On 12/19/10 06:52, spir wrote:
On Sun, 19 Dec 2010 03:37:37 -0600
Christopher Nicholson-Sauls ibisbase...@gmail.com wrote:
On 12/18/10 07:19, spir wrote:
Hello,
I cannot find a way to define methods (I mean member functions) outside
the main type-definition body:
struct X {}
void X.say () {writeln(I say!);}
==
Element.d(85): semicolon expected, not '.'
Do I overlook anything, or is this simply impossible? In the latter case,
what is the problem?
(In many languages, not only dynamic ones, method are or at least can be
defined apart.)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
As bearophile says, it just isn't the D way to do things.
But, if you absolutely must (or just want to, for playing sakes) there
are ways of faking it using opDispatch. Here's one I just tossed
together and tested (DMD 2.050) right now.
[code snipped]
Generally speaking, though, I'm not sure what the real value would be in
doing this in D. Did you have a particular use case in mind, or was it
just idle exploration?
Thank you very for this example use of opdispatch :-)
I'm still exploring the language (which I like very much, except for some
given features *). Actually, I just wanted to know whether it's possible,
because I'm used to this way and find it more practicle or readable in
various cases. But it is not a problem.
Denis
(*) Some inherited from C/C++ (unhelpful syntax or semantics, mainly), some
among the newest (too abstract or complicated, i'd say).
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
No problem. opDispatch has a number of possible uses. Another thing
I've done with it before is to wrap the message passing system from
std.concurrency, to ease defining message protocols. Basically I define
a message as a struct, then define an opDispatch that looks for the
pattern 'sendBLAH(...)' and forwards that to 'tid.send(BLAHMessage(...),
thisTid())' auto-magically. To make it really magical I had to create
some code-generation for the receiving end so it would provide an
argument to receive/receiveTimeout for each handleBLAH method I define.
It had a few little bugs/quirks though, which is why I haven't ever
shared it.
-- Chris N-S
Re: define methods apart
On 12/18/10 07:19, spir wrote:
Hello,
I cannot find a way to define methods (I mean member functions) outside the
main type-definition body:
struct X {}
void X.say () {writeln(I say!);}
==
Element.d(85): semicolon expected, not '.'
Do I overlook anything, or is this simply impossible? In the latter case,
what is the problem?
(In many languages, not only dynamic ones, method are or at least can be
defined apart.)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
As bearophile says, it just isn't the D way to do things.
But, if you absolutely must (or just want to, for playing sakes) there
are ways of faking it using opDispatch. Here's one I just tossed
together and tested (DMD 2.050) right now.
--
import std.stdio;
class Foo {
static addExternalMethod( void function( Foo ) fp, string id ) {
_methodRegistry[ id ] = fp;
}
private static void function( Foo )[ string ] _methodRegistry;
this ( string name ) {
_name = name;
}
@property const
string name () { return _name; }
private string _name;
void opDispatch ( string Id ) () {
if ( auto fp = Id in _methodRegistry ) {
(*fp)( this );
}
}
}
void _foo_sayHello (Foo self) {
writefln( Hello, I am %s., self.name );
}
static this () {
Foo.addExternalMethod( _foo_sayHello, sayHello );
}
void main () {
auto foo = new Foo( Grant );
foo.sayHello();
}
--
Of course, there is the obvious issue of the 'method' signatures having
to be the same, in this case. You'd have to find a better solution to
the 'registry' issue, at the very least, in order to make it really usable.
Generally speaking, though, I'm not sure what the real value would be in
doing this in D. Did you have a particular use case in mind, or was it
just idle exploration?
-- Chris N-S
Re: define methods apart
On Sun, 19 Dec 2010 03:37:37 -0600
Christopher Nicholson-Sauls ibisbase...@gmail.com wrote:
On 12/18/10 07:19, spir wrote:
Hello,
I cannot find a way to define methods (I mean member functions) outside
the main type-definition body:
struct X {}
void X.say () {writeln(I say!);}
==
Element.d(85): semicolon expected, not '.'
Do I overlook anything, or is this simply impossible? In the latter case,
what is the problem?
(In many languages, not only dynamic ones, method are or at least can be
defined apart.)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
As bearophile says, it just isn't the D way to do things.
But, if you absolutely must (or just want to, for playing sakes) there
are ways of faking it using opDispatch. Here's one I just tossed
together and tested (DMD 2.050) right now.
[code snipped]
Generally speaking, though, I'm not sure what the real value would be in
doing this in D. Did you have a particular use case in mind, or was it
just idle exploration?
Thank you very for this example use of opdispatch :-)
I'm still exploring the language (which I like very much, except for some given
features *). Actually, I just wanted to know whether it's possible, because I'm
used to this way and find it more practicle or readable in various cases. But
it is not a problem.
Denis
(*) Some inherited from C/C++ (unhelpful syntax or semantics, mainly), some
among the newest (too abstract or complicated, i'd say).
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: define methods apart
spir: Do I overlook anything, or is this simply impossible? Even if you find some trick to do it, it's not the D way. A language syntax is defined by its conventions too. Bye, bearophile
Re: define methods apart
On Saturday 18 December 2010 05:19:56 spir wrote:
Hello,
I cannot find a way to define methods (I mean member functions) outside
the main type-definition body:
struct X {}
void X.say () {writeln(I say!);}
==
Element.d(85): semicolon expected, not '.'
Do I overlook anything, or is this simply impossible? In the latter case,
what is the problem? (In many languages, not only dynamic ones, method are
or at least can be defined apart.)
It is not supported. Functions are either free and unconnected to a type, or
they're part of a type. You can't define one which is defined outside a type
and
yet considered part of that type. Declarations and definitions in general in D
cannot be split. And splitting up definitions by defining a part of something
elsewhere isn't supported at all - unless you count mixins, which just inject
code from elsewhere, so while from the programmer's perspective the code is
elswehere, from the compiler's perspective, it isn't really (since it's
effectively copy-pasted in).
The closest you can get to having member functions outside of a type is to call
functions on arrays as if they were member functions, as long as the first
parameter is an array and is the same type of array. There is a good chance
that
this will become true for _all_ types at some point (the term used for this is
uniform function call syntax), at which point, in a way, you'd be able to
define
functions for a type outside the type since then you could call any function
which took the type as its first parameter as if it were a member function of
that type. However, uniform function call syntax hasn't been implemented yet,
so
it only works for arrays.
- Jonathan M Davis
