Re: Ruby of the future: Goodbye to methods... PLEASE
- From: "netytan" <netytan@xxxxxxxxx>
- Date: 1 Jun 2006 09:44:13 -0700
Taking into account Joesbs very interesting post I think you're
right, that methods are objects but that they aren't usually
accessible, and so this is more about interface than anything else now.
Ideally I would like Methods to be Procs with all the implied
properties i.e. lexical scope etc.
Hence defining a method like this
....
def something(arg1, arg2)
... something ...
end
....
should be equivalent to binding
....
something = lambda do | arg1, arg2 |
... something ...
end
....
Then, there should be some equivalent way of accessing the two objects
and calling the two. This eliminates any difference between them so you
could use methods anywhere you would use Proc, and Proc anywhere you
would use methods.
That has to be an advantage. I'm not saying blocks should be removed,
they're a nice shorthand and not bad as far as syntactic sugar goes.
Maybe something like
Obj.method.pass puts
Obj.method pass puts
Obj.method <- puts
Or
Obj.method | puts |
I don't really care about the syntax of calling and passing things,
just that it be consistent between the two.
So, in summery:
* Remove Method and UnboundMethod
* Leave Blocks however add syntax for passing function/method names as
Blocks.
* Consistent way of treating methods and Proc.
I did say it was simple, but it's also very powerful. One of the best
things about Lisp is that you have one clear consistent way to use
things - this is slightly more so in Lisp-1 than Lisp-2.
Macros are special in that they compose code before the code is ever
run, at macro-expansion time. Macros are first-class in some Schemes,
in that they are data types and can be passed around etc. No standard
I'm aware of actually enforces first-class macros yet - this is
really the front line where things are being tested out.
Since any code I write is purposely portable and standard compliant I
haven't used them but Macros are more generally used to extend the
language, to write code. Passing them around serves little purpose, as
would passing around keywords such as def and class.
It's a subject that I find intensely interesting though so I will be
looking into it sometime in the future :).
I know that in OO you see things as messages however you can also pass
methods around in Smalltalk, Python and Io to name a few. These are all
Purely OO languages, to varying degrees. If you can do both in these
languages seamlessly then why not allow it in Ruby.
Differential inheritance actually comes from prototype based OO.
Here's a short passage that I found about it on Google.
"Differential Inheritance is a common prototype-oriented model that
uses the concept that most objects are derived from other, more generic
objects, and only differ in a few small aspects. Each object maintains
a reference to its prototype and a table of properties that are
different."
Class based OO has certain disadvantages, one of which is a reduction
in RAD. I suspect that replacing Class with prototype could make
development even faster - something Ruby is already well suited for.
Mixins are different entirely; involving classes and simply requires
definition and binding to be done at runtime :).
Anyway that doesn't really have anything to do with the rest of this
thread, just something I'm interested in exploring.
Take care guys,
Thanks :).
Mark,
.
- Follow-Ups:
- Re: Ruby of the future: Goodbye to methods... PLEASE
- From: Martin DeMello
- Re: Ruby of the future: Goodbye to methods... PLEASE
- From: Dave Burt
- Re: Ruby of the future: Goodbye to methods... PLEASE
- References:
- Prev by Date: Re: How do you know what methods do not require a dot prefix
- Next by Date: Virtualization Windows APP within Browser with Ruby/RoR?
- Previous by thread: Re: Ruby of the future: Goodbye to methods... PLEASE
- Next by thread: Re: Ruby of the future: Goodbye to methods... PLEASE
- Index(es):
Relevant Pages
|