Very cool.
On Wed, Apr 1, 2009 at 8:47 AM, Rich Hickey wrote:
>
>
> I've added get-method (SVN 1338).
>
> (derive ::Circle ::Shape)
> (derive ::Rect ::Shape)
>
> (defmulti area :Shape)
>
> ;note - you can name methods
> (defmethod area ::Shape area-shape [x] nil)
>
> (get-method area ::Rect)
> #
On Apr 1, 2009, at 14:47, Rich Hickey wrote:
> I've added get-method (SVN 1338).
Great, thanks!
> Note how you can name methods for diagnostic purposes. This doesn't
> introduce names into the namespace, just puts a name on the fn object.
It's also useful for recursive calls, if you are sure y
On Mar 31, 12:45 pm, Konrad Hinsen wrote:
> On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > Here are some problems/limitations of existing OO/GF systems that I
> > don't intend to repeat:
>
> ...
>
> I agree that these are not desirable features. I have had to work
> around some of them man
On 31.03.2009, at 21:48, Konrad Hinsen wrote:
> On 31.03.2009, at 18:50, Mark Engelberg wrote:
>
>> On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
>> wrote:
>>> I think this should be sufficient to cover all cases you mentioned,
>>> but of course it needs to be tried in practice.
>>
>> I think y
On Mar 31, 2:25 pm, Rich Hickey wrote:
> On Mar 31, 2:18 pm, mikel wrote:
> What about predicate, or rule based dispatch - why hardwire the notion
> of types, traversal or matching?
Those are different names for the same pieces.
> This is simply an exhausting amount of talk - how about a p
On 31.03.2009, at 18:50, Mark Engelberg wrote:
> On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
> wrote:
>> I think this should be sufficient to cover all cases you mentioned,
>> but of course it needs to be tried in practice.
>
> I think your idea of specifying a sequence of items to try in the
On Mar 31, 2:18 pm, mikel wrote:
> On Mar 31, 11:45 am, Konrad Hinsen wrote:
>
>
>
> > On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > > Here are some problems/limitations of existing OO/GF systems that I
> > > don't intend to repeat:
>
> > ...
>
> > I agree that these are not desirable fe
On Mar 31, 11:45 am, Konrad Hinsen wrote:
> On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > Here are some problems/limitations of existing OO/GF systems that I
> > don't intend to repeat:
>
> ...
>
> I agree that these are not desirable features. I have had to work
> around some of them man
On Tue, Mar 31, 2009 at 9:45 AM, Konrad Hinsen
wrote:
> I think this should be sufficient to cover all cases you mentioned,
> but of course it needs to be tried in practice.
I think your idea of specifying a sequence of items to try in the
dispatching function, at the point of definition for the
On Mar 31, 2009, at 16:32, Rich Hickey wrote:
> Here are some problems/limitations of existing OO/GF systems that I
> don't intend to repeat:
...
I agree that these are not desirable features. I have had to work
around some of them many times in the past. Traditional OO combines
aspects that
Many thanks for the long and reasoned reply (and to mikel as well for adding
his thoughts). I apologize for my slowness in understanding the nature of
multimethods- it's tricky converting my existing knowledge ;)
On Tue, Mar 31, 2009 at 10:32 AM, Rich Hickey wrote:
>
>
> Here are the areas I'm lo
Hi,
2009/3/31 Rich Hickey
> Here's how I think about it:
>
> - Hierarchies have nothing to do with multimethods/GFs per se.
True,
So, along the lines of my previous post, could it be made possible to let
the user provide its own multimethods "candidate dispatch-values filtering"
and "candidat
On Mar 31, 9:32 am, Rich Hickey wrote:
> Can we please move forward in trying to implement something better
> than CLOS GFs?
Maybe. Let me know when you think of something better, and I'll do the
same. When we agree, I'll toss my GF implementation out the door. In
the meantime, it's made my
Here are some problems/limitations of existing OO/GF systems that I
don't intend to repeat:
A) They provide only a single declaration point for all superclasses
of a class
B) They consider the local declaration order of superclasses to be
significant
C) They conflate hierarchies and graphs contai
On Mar 28, 6:30 pm, David Nolen wrote:
> Having thought a little about multiple inheritance when implementing Spinoza
> I also ran into this problem. However at the time I wasn't hindered by
> multifn dispatch as much as the fact that parents cannot be ordered (because
> calling parents on a ta
Having thought a little about multiple inheritance when implementing Spinoza
I also ran into this problem. However at the time I wasn't hindered by
multifn dispatch as much as the fact that parents cannot be ordered (because
calling parents on a tag returns a set) as pointed out by Mark. I understa
16 matches
Mail list logo
