Little Things

G

Gregory Brown

still. shorter is good. maybe something like

__( obj ).send message
Click to expand...

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"
 
G

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"
Click to expand...

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

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).
Click to expand...

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
Click to expand...

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)
Click to expand...

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
 
A

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.
Click to expand...


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

-a
 
T

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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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
Click to expand...

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.
 
T

Trans

Gregory said:
Oh, sorry ara. I was actually talking about the arrow.
Click to expand...

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.
 
G

Gregory Brown

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

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].
Click to expand...

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 :)
 
G

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?
Click to expand...

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
 
T

Trans

[email protected] said:
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)
Click to expand...

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
Click to expand...

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).
Click to expand...

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.
 
E

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
 
D

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.
Click to expand...

! 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.
Click to expand...

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)
 
J

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.
Click to expand...

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

James Edward Gray II
 
E

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

<Button ...> display is fine, except for two things 1
I require a little help... 1
Opening and appending to file in Python3 6
Opening and appending to file in Python3 0
What is the most astounding C++ syntax construct? 0
Problem with KMKfw libraries 1
What is AI programming to us non-bigtech programmers? 4
Another Password Confirmation 2

Members online

Total: 31 (members: 1, guests: 30)
Robots: 162

Forum statistics

Threads
473,756
Messages
2,569,534
Members
45,007
Latest member
OrderFitnessKetoCapsules

Latest Threads

Top