Little Things

[Gregory Brown]

still. shorter is good. maybe something like

__( obj ).send message

This is a really bad idea, but I might as well put it out there. I
don't think it's possible to do presently, but I think it's about as
ugly as everything else suggested, no more, no less.

A backwards send arrow

obj <- "message"

 

[Gregory Brown]

This is a really bad idea, but I might as well put it out there. I
don't think it's possible to do presently, but I think it's about as
ugly as everything else suggested, no more, no less.

A backwards send arrow

obj <- "message"

Oh jeez, should have read the full thread. Guess this bad idea
already came up

 

[Trans]

I'm sorry, T. You know I never meta-programmer I didn't like!

BTW LOL!

T.

 

[gwtmp01]

The operator you suggest however would probably have to be flipped to
avoid ambiguity with Symbol#@-. Eg. recv < -:class (I know rare. but
possible).

The mnemonics are all wrong if you flip it:

obj <- message # sending the message to the object
obj -> message # sending the object to the message?

You have to think of <- as a two character operator. Of course
the parser would also have to think of it that way. There would have to
be some white space to have it parse as '<' and '-' separately. My only
point is that it can be parsed, but a syntax that was a bit more
stable with respect to white space would certainly be better.

As for the class search idea, that can be done easily enough with:

recv.as(BasicObject) -> :class

This introduces the same problem I pointed out with respect to the
semantics of #send but this time with #as. In fact it is worse because
you've got normal method call syntax but completely different semantics
since
recv.as(BasicObject)
will parse as an expression to be evaluated as the lhs of the '->'
operator.
What kind of object would #as return and how would the -> operator know
about the receiver?

To outline, this would give ruby a complete set of dispatch operators:

. literal
<- dynamic
<<- functional (dynamic)
<~ pervasive (dynamic)

Having a syntax for starting method lookup in a particular class also
gives you a way to call a method that has been redefined without having
to play games with aliases:

class A; def m; end; end
class B < A; def m; end; end

class C
def example
self.m # calls B#m
(self, A) <- :m # calls A#m (kind of ugly syntax though)
end
end


Gary Wright

 

[ara.t.howard]

This is a really bad idea, but I might as well put it out there. I
don't think it's possible to do presently, but I think it's about as
ugly as everything else suggested, no more, no less.

but it's possible NOW. see the latest annouce on the list!

-a

 

[Gregory Brown]

but it's possible NOW. see the latest annouce on the list!

Oh, sorry ara. I was actually talking about the arrow.

 

[ara.t.howard]

Oh, sorry ara. I was actually talking about the arrow.

ah. well, they are both ugly, but i chose the one that's possible and ugly
;-)

cheers.

-a

 

[Trans]

The mnemonics are all wrong if you flip it:

obj <- message # sending the message to the object
obj -> message # sending the object to the message?

You have to think of <- as a two character operator. Of course
the parser would also have to think of it that way. There would have to
be some white space to have it parse as '<' and '-' separately. My only
point is that it can be parsed, but a syntax that was a bit more
stable with respect to white space would certainly be better.

I realize it's not as intuitive at first glance, but i don't think it's
"all wrong". in fact, "->" is what Perl and PHP both use rather then a
'.' so there is already plenty of precedence for it. the mnemonic
disconnect you suggest really comes from calling the obj a "receiver".
if it'll help we can avoid that term and find a better way to "read"
this.

This introduces the same problem I pointed out with respect to the
semantics of #send but this time with #as.

Ah, good point. Damn, and I really liked the #as method too.

In fact it is worse because
you've got normal method call syntax but completely different semantics
since
recv.as(BasicObject)
will parse as an expression to be evaluated as the lhs of the '->'
operator.
What kind of object would #as return and how would the -> operator know
about the receiver?

Well, that's not really an issue i don't think. It just returns a
suitable proxy. But your first point makes it rather mute in any case.

Having a syntax for starting method lookup in a particular class also
gives you a way to call a method that has been redefined without having
to play games with aliases:

class A; def m; end; end
class B < A; def m; end; end

class C
def example
self.m # calls B#m
(self, A) <- :m # calls A#m (kind of ugly syntax though)
end
end

Agree with that, which is what I've used #as for too. Can the (self, A)
syntax you suggest really work w/o problem? I fear it might go against
Matz's no look-ahead rule for the parser. Is that true? And if it is,
have you any other suggestion for it?

T.

 

[Trans]

Oh, sorry ara. I was actually talking about the arrow.

The arrow is more ugly!? in that case try writting some heavy meta-code
using Pervasives and __(obj) and let me know how it goes ;-) [trust me
I've done it].

T.

 

[ara.t.howard]

Oh, sorry ara. I was actually talking about the arrow.

The arrow is more ugly!? in that case try writting some heavy meta-code
using Pervasives and __(obj) and let me know how it goes ;-) [trust me
I've done it].

it's done!

http://groups-beta.google.com/group...05a36/e6b4110167555781?hl=en#e6b4110167555781

test it and let me know

-a

 

[Gregory Brown]

Oh, sorry ara. I was actually talking about the arrow.

The arrow is more ugly!? in that case try writting some heavy meta-code
using Pervasives and __(obj) and let me know how it goes ;-) [trust me
I've done it].

No. I see the arrow to be equivalent to __(obj) and prettier than an
explicit Pervasive object.
I suggested the arrow since it was the best I could come up with, but
I should have read the thread before to see it was already suggested.
I would have been kinder then, perhaps, since I thought I was making
fun of myself

 

[gwtmp01]

Agree with that, which is what I've used #as for too. Can the
(self, A)
syntax you suggest really work w/o problem? I fear it might go against
Matz's no look-ahead rule for the parser. Is that true? And if it is,
have you any other suggestion for it?

I don't know quite enough about the grammar to say if that syntax works
or not. I suspect that it isn't any more of a problem than the current
parallel assignment syntax:

(a,b) = :foo, :bar

The only thing different is the operator. But I really don't like that
syntax myself. My main point is that there are different sorts of
'dispatches'
you might want to have available and that the standard method syntax
probably
shouldn't be overloaded (e.g. Object#send) to access those different
types
of dispatches (for the same reasons that dot itself isn't a method based
operator)

recv.method arg1 # literal method
recv OP1 :name, arg1 # dynamic method
recv OP2 Klass, :name, arg1 # dynamic with modified method lookup

I'm not sure what OP1 or OP2 might be that would look reasonable,
have some
sort of reasonable mnemonic, and also not screw up the grammar. Maybe:

recv.method(arg1) # literal method
recv.*method, arg1) # dynamic (mnemonic: * is a wild card?)
recv.**(Klass, :method, arg1) # dynamic with modified lookup
recv.*!method, arg1) # private also
recv.**!(Klass, :method, arg1) # modified and private


I think different types of dispatch operators would end up having
clearer
semantics than 'magic' methods (like BasicObject#send). I don't have
any
great ideas about the actual syntax though. I don't like the
Pervasive class
idea (nor the name itself even if the idea were to catch on).


Gary Wright

 

[Trans]

I don't know quite enough about the grammar to say if that syntax works
or not. I suspect that it isn't any more of a problem than the current
parallel assignment syntax:

(a,b) = :foo, :bar

The only thing different is the operator. But I really don't like that
syntax myself. My main point is that there are different sorts of
'dispatches'
you might want to have available and that the standard method syntax
probably
shouldn't be overloaded (e.g. Object#send) to access those different
types
of dispatches (for the same reasons that dot itself isn't a method based
operator)

And I agree. And I think the syntax you have suggested is pretty close.

recv.method arg1 # literal method
recv OP1 :name, arg1 # dynamic method
recv OP2 Klass, :name, arg1 # dynamic with modified method lookup

Hmm... because the method will always be a string or symbol, a class or
module could be distinguished, so looking at your template I now see
that it's possible for OP1 == OP2:

obj -> Base, :name, *args

And I wonder if the Base form could grant access to private space too?
The Base form is pretty meta-hackery in itself so I think that would be
okay. Then we would't need an "OP3" for private access. Just do:

obj -> (obj ~> :class), :name, *args

where ~> is pervasive send.

I'm not sure what OP1 or OP2 might be that would look reasonable,
have some
sort of reasonable mnemonic, and also not screw up the grammar. Maybe:

recv.method(arg1) # literal method
recv.*method, arg1) # dynamic (mnemonic: * is a wild card?)
recv.**(Klass, :method, arg1) # dynamic with modified lookup
recv.*!method, arg1) # private also
recv.**!(Klass, :method, arg1) # modified and private


I think different types of dispatch operators would end up having
clearer
semantics than 'magic' methods (like BasicObject#send). I don't have
any
great ideas about the actual syntax though. I don't like the
Pervasive class
idea (nor the name itself even if the idea were to catch on).

I know the mnemonic isn't great, but '->' really is common as a
dispatch op. Anyone who's done their share of Perl or PHP coding is
going to feel right at home with it. And I think the rest of us can
grow accustomed. So maybe give it a chance? B/c if so, I think this is
looking pretty damn nice!

T.

 

[Evan Weaver]

Regarding 'funcall', I would rather support a 'send'-derived word which
reflects the message-passing nature of what is really going on. Also, my
brain reads 'funcall' most intuitively as 'FUNCtion ALL'. However I
think the tradition of ! modifying the receiver makes 'send!' for
private methods not good. I don't have a better suggestion, though.

Regarding overriding 'send', I don't think that any method is too
important to be overridden. Perhaps '__send' to always call the original
version would be ok, but the idea of permanently disallowing some
operation because it's "important" doesn't sit well with me. If I want
to break Ruby, I want it to graciously break, instead of saying 'No'.

Regarding the name of singleton classes, I think 'eigenclass' is ok. I
am partial to 'shadow_class', because the singleton class shadows the
real class. I would like to be allowed to instantiate new objects from
them, as a sort of backhanded prototyping.

Evan Weaver

 

[dblack]

Hi --

Regarding 'funcall', I would rather support a 'send'-derived word which
reflects the message-passing nature of what is really going on. Also, my
brain reads 'funcall' most intuitively as 'FUNCtion ALL'. However I
think the tradition of ! modifying the receiver makes 'send!' for
private methods not good. I don't have a better suggestion, though.

! doesn't mean modifying the receiver, though. It means "dangerous".
It's used often for modifying receivers, but that's never been what
Matz says it means; that's just one form of danger.

Regarding overriding 'send', I don't think that any method is too
important to be overridden. Perhaps '__send' to always call the original
version would be ok, but the idea of permanently disallowing some
operation because it's "important" doesn't sit well with me. If I want
to break Ruby, I want it to graciously break, instead of saying 'No'.

Regarding the name of singleton classes, I think 'eigenclass' is ok. I
am partial to 'shadow_class', because the singleton class shadows the
real class. I would like to be allowed to instantiate new objects from
them, as a sort of backhanded prototyping.

You can do something along these lines by cloning objects:

irb(main):003:0> a = Object.new
=> #<Object:0xb7f34c8c>
irb(main):004:0> def a.x; puts "hi"; end
=> nil
irb(main):005:0> b = a.clone
=> #<Object:0xb7f22ba4>
irb(main):006:0> b.x
hi


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[James Edward Gray II]

Hi --



! doesn't mean modifying the receiver, though. It means "dangerous".
It's used often for modifying receivers, but that's never been what
Matz says it means; that's just one form of danger.

For example, exit!() does not modify a receiver.

James Edward Gray II

 

[Evan Weaver]

Re David: But I don't want to copy the data, just the behavior.

Re James: You're right. If I've gotten used to those, I can get used to
'send!'.

Evan Weaver

 

[Evan Weaver]

Mauricio has already implemented (sort of) what I want regarding .new. I
didn't realize that this sort of worked in 1.8.2, except for the
inheritance persistence (which is important to me). Was it removed as a
side-effect of some other optimization?

http://eigenclass.org/hiki.rb?cmd=view&p=prototype-based+OOP

Evan Weaver