signal/slot like mechanism
Hi guys, i was just wondering if some notification mechanism ( signal/slot alike ) was planned in perl 6, like they already are in glib and qt ? Or is it maybe better if implemented in some perl6 module (don't think so) ?? Or maybe this matter has already been discussed and is now closed ??? And no, i'm not planning on doing it myself :-/ -- One good thing about music, Well, it helps you feel no pain. So hit me with music; Hit me with music now. -- Bob Marley, "Trenchtown Rock"
Re: Object spec
Sam Vilain wrote: >Associations *are* fundamental object things. Presenting them in terms of >attributes is the real hack. Associations *are* fundamental things, but I don't think they are part of an object. They describe relationships between objects and should exist independantly and orthogonal to them. Dave Whipp wrote: > An association is a mechanism that permits one object to navgigate to > another. If the association is bidirectional, then it is possible to > also navigate from the target back to the source. Each direction of > navigation should be given a unique identifer. Category theory has something to say about this. I hope I can provide an essence of it, despite my limited understanding of the subject... A category is defined by a collection of elements (objects in this case) and a number of morphisms (relations) that provide mappings between the different elements. There are many different kinds of morphisms: epimorphisms (one-to-), monomorphisms (-to-one), isomorphisms (one-to-one), polymorphisms (-to-many) and so on. In category theory, morphisms are dual, so that for each relationship represented by an arrow between two objects, there is a reciprocal relationship travelling back down the arrow in the opposite direction. Traditional databases and object systems are based on set theory. Set theory is in fact just one kind of theory that is described by category theory (think of Category Theory as a class and Set Theory as an instance). The category morphisms that are defined by set theory are 'identity' and 'contains' (insert general paraphrasing and hand-waving warning here). The 'identity' isomorphism gives each element in the set a unique identifier so that you know which one you're talking about at any time. 'contains' is a polymorphism that defines which elements are contained by which other elements. If you want to make it an ordered set, then you need to add another morphism, 'before' (and its dual morphism 'after') which tells you which of any two elements in a set is ordered before the other. If you want to make a tuple, hash, queue, stack, bag, stream or multi-coloured, cross-referenced, hyper-indexed, double-camel Larry space in 9 + 3i dimensions, then you just need to add a few more morphisms that define those extra relations that are characteristic of that kind of information space. In summary: Category == [ Elements, Morphisms ]# math terminology == [ Objects, Associations ] # programming == [ Records, Relations ] # database > An association is either "consitant", or "inconsitant". I think it is better to assume that there is no such thing as an inconsistent morphism. If the shoe doesn't fit, then don't wear it! Find another shoe or go barefoot. :-) > While it it is obvious that associations can be implemented using > attributes, it seems to me that, to do so, is [ ...not so good... ] Agreed. Associations are no more part of an object than an electric current is part of an electron. The field is defined by the interaction between fundamental particles but is not an inherent part of the particles themselves (wave/particle duality and other quantum mechanical chicanery aside). The only reason that we are currently forced to use attributes to represent our relations is because our OO systems and databases are based on set theory. An object or database record is conceptually nothing more than a set containing attributes. We define relations using attributes as foreign keys because there's no other way to do it. If instead we borrow the conceptual model from category theory and provide a mechanism for defining elements and relations *separately*, then it should be possible to build all kinds of fancy information spaces with any number of different inter-element relationships defined. The only language that I'm aware of that implements something like this is CAML (although I'm sure there must be others). Reading from http://caml.inria.fr/ercim.html : "It is possible to define a type of collections parameterized by the type of the elements, and functions operating over such collections. For instance, the sorting procedure for arrays is defined for any array, regardless of the type of its elements." Anyway, the gist of this long rambling post is that In My Humble Opinion, if Perl 6 is to provide the ability to define associations between objects, then it should do so as part of a larger category mechanism rather than as an extension to the class/object mechanism. A
Re: signal/slot like mechanism
> Hi guys, i was just wondering if some notification mechanism (
> signal/slot alike ) was planned in perl 6, like they already are in
> glib and qt ?
class Signal {
has @.dest;
method emit($code) { $code($_) for @.dest }
method attach($obj) { push @.dest: $obj }
}
class Foo {
has Signal $.valueChanged is public;
has $.value is public;
method value($newval) {# Overriding default accessor
$.value = $newval;
emit $.valueChanged: { .($newval) };
$.value
}
}
my Foo $a, $b;
$a.valueChanged.attach($b, { $b.value($_) });
Or something like that. Already supported :)
It's neat how powerful the closure is. I can't wait until I
understand continuations!
> And no, i'm not planning on doing it myself :-/
Planning on changing your plans now?
Luke
Re: Object spec
--- Andy Wardley <[EMAIL PROTECTED]> wrote: > Associations *are* fundamental things, but I don't think they are > part of an object. They describe relationships between objects and > should exist independantly and orthogonal to them. Agreed. Is there any reason that shouldb't be done with something like use Associasions; associate( $foo => $bar, @opts ); # opts defining association type I see no real desperate need for that to be an integrally linguistic mechanism, tho perhaps I'm being dense again. Seems to me a module could do all that was needed, in p5 and/or p6. > Dave Whipp wrote: > > An association is a mechanism that permits one object to navgigate > > to another. If the association is bidirectional, then it is possible > > to also navigate from the target back to the source. Each direction > > of navigation should be given a unique identifer. Easy enough for a module to keep and internal doubly-linked list of objects that describe the relationships of things it has been told to attend. > There are many different kinds of morphisms: epimorphisms (one-to-), > monomorphisms (-to-one), isomorphisms (one-to-one), polymorphisms > (-to-many) and so on. In category theory, morphisms are dual, > so that for each relationship represented by an arrow between two > objects, there is a reciprocal relationship travelling back down the > arrow in the opposite direction. So the relation object for any given registered object could have subtrees that identify all these. It seems simple. Am I missing something? > If you want to make it an ordered set, then you need to add another > morphism, 'before' (and its dual morphism 'after') which tells you > which of any two elements in a set is ordered before the other. Sensible, and still reasonably easy to implement > I think it is better to assume that there is no such thing as an > inconsistent morphism. If the shoe doesn't fit, then don't wear it! > Find another shoe or go barefoot. :-) hmm... maybe not. Inheritance is an assosiation of sorts, isn't it? (please don't let that open another can of worms, lol...) But the child object knows it's parent, and can inherit methods and atributes, while the parent can know nothing about it's child in standard OOP structure. That's an inconsistent assosiation, isn't it? I only mention it because, though I can't really think of a good example of when it would be needed, I'd hate to say you can't *have* one, just because Easier to code and maintain for flexibility from the start. :) > Associations are no more part of an object than an electric > current is part of an electron. The field is defined by the > interaction between fundamental particles but is not an inherent > part of the particles themselves (wave/particle duality and other > quantum mechanical chicanery aside). But I *LIKE* quantum mechanical chicanery! >:O} Still, I concur. The object shouldn't need to know or care who else "owns" it. My coffee cup doesn't. But if the program needs to identify whose coffee cup it is, there should be a way. The Cup object shouldn't be required to have an owner attribute dictated by a theoretical Association system in the language. Many applications, most, I'd say, won't need it, and I'd rather skip the overhead. If I need it, I'll pull in the necessary module and set up the relationships as required. Now it *would* be nice if the Association module could help shortcut that and provide some syntactic sweetener, but for that I don't even mind if it's Aspartame. ;o] > If instead we borrow the conceptual model from category theory and > provide a mechanism for defining elements and relations *separately*, > then it should be possible to build all kinds of fancy information > spaces with any number of different inter-element relationships > defined. I must admit I like this idea -- it's *feels* elegant, but I have no idea off the top of my head how you would *use* it. Can you give me an implementation example, in theoretical code? > Anyway, the gist of this long rambling post is that In My Humble > Opinion, if Perl 6 is to provide the ability to define associations > between objects, then it should do so as part of a larger category > mechanism rather than as an extension to the class/object mechanism. Maybe. I'm almost convinced, but I need to see more concrete examples. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: signal/slot like mechanism
At 6:27 PM + 3/6/03, Yannick Le Saint wrote: Hi guys, i was just wondering if some notification mechanism ( signal/slot alike ) was planned in perl 6, like they already are in glib and qt ? I'm not exactly sure what you're looking for, since I'm not too familiar with qt or glib, but if you mean will there be a mechanism to register watcher subs that get called when things happen internally (such as when a method is defined or redefined, or a class changes, or something of the sort) then yes, we'll be doing that. It solves a fairly thorny problem with making efficient specific solutions in the face of a general problem, so there'll be built-in facilities for it. (What it means for parrot, specifically, is that we can build call structures and code designed specifically for whatever is the current set of methods and class behaviours, knowing that if something changes we can just rebuild our stuff based on the new layout because we've got a notification method registered) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec [x-adr][x-bayes]
At 2:08 PM +1300 3/7/03, Sam Vilain wrote: As long as mechanisms are put in place to allow modules to bypass object encapsulation and private/public constraints, and given that Parrot will have no XS, It wouldn't be wise to jump from "Parrot won't do perl 5's XS scheme" to "Parrot won't have a way to write code for it in C". It will, arguably, be *easier* in parrot to write parts of your program in C, thus making it more likely that less of an object will be guaranteed to be done entirely in parrot-space. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec [x-adr][x-bayes]
On Sat, 08 Mar 2003 06:58, Dan Sugalski wrote: > At 2:08 PM +1300 3/7/03, Sam Vilain wrote: > >As long as mechanisms are put in place to allow modules to bypass > > object encapsulation and private/public constraints, and given that > > Parrot will have no XS, > > It wouldn't be wise to jump from "Parrot won't do perl 5's XS scheme" > to "Parrot won't have a way to write code for it in C". It will, > arguably, be *easier* in parrot to write parts of your program in C, > thus making it more likely that less of an object will be guaranteed > to be done entirely in parrot-space. OK. Perhaps those structures should have a method/PMC that they must export which will dump their internal state into a near equivalent Parrot data structure rather than just having serialisation methods, for the sake of the tools that want to traverse it rather than just freeze/thaw it to a stream. ie, something that extracts their state and can be passed to `bless' et al to reconstruct the original object. The structure freezer & heater can ask objects to present themselves as core types for serialisation. I think this would be a great debugging win as well. -- Sam Vilain, [EMAIL PROTECTED] Real computer scientists like C's structured constructs, but they are suspicious of it because its compiled. (Only Batch freaks and efficiency weirdos bother with compilers, they're s un-dynamic.)
