Re: Ruby of the future: Goodbye to methods... PLEASE



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,

.



Relevant Pages

  • Re: reply the answer
    ... need a prototype for putsbecause it returns int and has no ... const char *, not char *. ... prototype is in scope that says it is okay to pass an argument ... Whether the definition of puts includes a prototype is not ...
    (comp.lang.c)
  • Re: Excel 2003 / 2007 function
    ... In Excel 2007, it has a discerning habit of opening spreadsheets that have ... about the formula bar that allows you enable macros. ... The 2003 user puts an 'x' in certain cells to selection size, color, ...
    (microsoft.public.excel)
  • Re: Comments on EPL Boxing Day.
    ... > passing to the wings until someone puts the ball up to ...
    (rec.sport.soccer)
  • Re: #define alternative for Ruby
    ... Binding.of_caller do |binding| ... This is because of the ambiguity in line B: "puts var1" could be referring ... macros would be fine here - but only if these macros were expanded at ... parse time. ...
    (comp.lang.ruby)
  • Re: reply the answer
    ... need a prototype for putsbecause it returns int and has no ... const char *, not char *. ... prototype is in scope that says it is okay to pass an argument ... Whether the definition of puts includes a prototype is not ...
    (comp.lang.c)