On Feb 10, 2009, at 7:45 PM, Reid T. wrote:
thanks,
reid
I could be entirely wrong on this, but http://macruby.org seems to
describe something like what you were looking for?
Just a thought.
-Zac
William J. wrote:
require ‘inline’
for x in -39…39 do
inline do |builder|
double zi2 = 0.0;
zi = temp + temp + ci;
}"let cr = y - 0.5 and
if zi2 + zr2 > bailout then
let i = iterate
(float x / 40.0) (float y / 40.0) in
System.Console.Write( ( if 0 = i then “*” else " " ) )
done
donelet start_time = Sys.time ()
let _ = mandelbrot ();
print_endline “”;
System.Console.Write (Sys.time () - start_time)
Using the built-in type complex makes the program shorter but
slower.
open Math.Complex;
let max_iterations = 1000
let iterate cmp =
let rec loop z i =
if i > max_iterations then
0
else
if magnitude z >= 2.0 then
i
else
loop (z * z + cmp) (i + 1)
in
loop zero 1
let mandelbrot () =
for y = -39 to 38 do
print_endline “”;
for x = -39 to 38 do
let i = iterate
(complex ((float y / 40.0) - 0.5) (float x / 40.0)) in
System.Console.Write( ( if 0 = i then “*” else " " ) )
done
done
let start_time = Sys.time ()
let _ = mandelbrot ();
print_endline “”;
System.Console.Write (Sys.time () - start_time)
Vetrivel V. wrote:
BAILOUT = 16
I think that this should be 4.
David M. wrote:
However, you should also realize that both Perl and
Javascript have a few similar features that make Ruby actually stricter
than either.
Similarities exist because Ruby is OOPL, and supports much broader
domain and programming paradigm than that in which and for which Perl
was designed and invented. Ruby is OOPL from the start, and has to be
able to model both geriatric pyramid organizations as well as flat
object organizations. The two indeed are orthogonal. However, OO has not
totally relaxed all the rules and does not promote a kind of anarchy one
could create with JavaScript and Perl.
The examples I gave both revolve around the fact that in
Perl and Javascript, functions (or subroutines) are just that. They can
be used as methods, and thus related to an object or a class, but they
are not inherently tied to that object.In Ruby, however, I can’t use a method from one class on a method from
another class, unless the two classes are related. I also can’t use a
class as a module. In other words, it’s the exact same sort of static
type checking, protect-you-from-yourself mentality as Java.
Though the advent of OO enabled us to much better cope with complex,
parallel and concurrent systems all of which are also elements of chaos,
OO itself is not chaotic and does not, as I have already said, promote
anarchy, which you are suggesting. There are rules that have to be
adhered to, only they are much more relaxed than are rules in
hierarchical structured pyramids of structured organizations. OO
organizations are flat and they accept and tolerate orthogonal concepts,
something unimaginable in pyramid structural organizations and
programming. There are rules that govern the freedom of selecting
procedural or structured methods, and when to abide by the orthogonal OO
principles. Failing to understanding these principles leads to chaos and
anarchy. The fact that you see meritocracy in the same light as
aristocracy is one such example of poor understanding of classification
and membership, or inheritance, aggregation, association and delegation
for that matter. In procedural languages you have to enforce these rules
yourself, in OO ideally the language enforces these concepts. Module is
not a class, which is not only true in Ruby but also in the OO bible -
Booch’s OOA/D. This can be said for all general OO methodologies. And
lastly, an instance method should not be treated as a loosely defined
function, nor should an object exhibit some foreign behaviour of some
arbitrary function, it totally violates encapsulation. Your propositions
and suggestions translate into total chaos and anarchy, where any
identity could be shared among all members of the universe (read any
domain)!
Except that Ruby enforces the aristocracy with respect to which methods
belong to which classes.
You are ignoring the merits on which a pure OO class enforces membership
rights. This unjustly is often seen as an anthropological attribute
objects have, but many objects are actors and actors are subjects with
responsibilities and behaviours, by which you classify them. You are
pushing aristocracy where it has no place. True there are objects that
only exist to carry a state, and they do have their place in the
universe as passive entities born with a silver spoon in their mouth,
one might say. However, not much would be happening if objects with
behaviour would not exist. Ask yourself, what connotation is ascribed to
the above mentioned property: “born with a silver spoon in your mouth”,
and on the other hand what the orthogonal connotation ascribed to the
phrase “well earned” is?
Except Perl is not strictly procedural, and Javascript actually has a
very nice prototypal object system.
This is is pure baloney. Perl was designed as such, and OO is only it’s
extension - a bonus so to speak, which becomes a tremendous burden to
the language, and very quickly even larger burden to the developer as
well as the project as it grows beyond certain level of complexity. The
same is true for JavaScript, which, metaphorically speaking, became of
old age only after ten years of it’s existence.
Cheers, have fun!
Reid T. wrote:
William J. wrote:
CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
everything compiled with debug except mandInC ). -rwxr-xr-x 1
rthompso staff 7104 2009-02-10 23:36 mandInC
To make timing more accurate, let’s calculate the set 100 times
but draw it only 1 time.
Result: 1.99286559999999 (laptop with 2GHz Pentium M)
(** Note that bailout has been changed. **)
let bailout = 4.0
let max_iterations = 1000
let iterate ci cr =
let rec loop zi zr i =
if i > max_iterations then
0
else
let temp = zr * zi and
zr2 = zr * zr and
zi2 = zi * zi in
if zi2 + zr2 > bailout then
i
else
loop (temp + temp + ci) (zr2 - zi2 + cr) (i + 1)
in
loop 0.0 0.0 1
let mandelbrot n =
for y = -39 to 38 do
if 1 = n then print_endline “” else ();
for x = -39 to 38 do
let i = iterate
(float x / 40.0) (float y / 40.0 - 0.5) in
if 1 = n then
System.Console.Write( ( if 0 = i then “*” else " " ) )
else ();
done
done;;
let start_time = Sys.time () in
for iter = 1 to 100 do
mandelbrot iter
done;
print_endline “”;
System.Console.Write (Sys.time () - start_time);
print_endline “”;
Igor P. wrote:
OO itself is not chaotic and does not, as I have already said, promote
anarchy, which you are suggesting.
Was I suggesting anarchy? I thought I was suggesting a specific feature:
Rip a method out of one class and apply it to another.
I fail to see how that’s more inherently anarchistic than:
- Re-opening classes at runtime
- Redefining methods, or whole classes, also at runtime
- Adding a method or mixing a module into just one instance
- All of the above with user input (eval)
- Doing no type checking whatsoever
- Overriding basic operators (make 2+2==5)
- Corrupt basic assumptions (make nil.nil? false) and crash
Ruby’s strength is in what you’re calling “anarchy” – except when you
choose to call it “flexibility”.
There are rules that have to be
adhered to, only they are much more relaxed than are rules in
hierarchical structured pyramids of structured organizations.
[snip]
There are rules that govern the freedom of selecting
procedural or structured methods, and when to abide by the orthogonal OO
principles. Failing to understanding these principles leads to chaos and
anarchy.
You’ve certainly not done a good job of explaining or defining such
rules.
The fact that you see meritocracy in the same light as
aristocracy
Show me where I said that.
In procedural languages you have to enforce these rules
yourself, in OO ideally the language enforces these concepts.
Erm… Why aren’t you using Java again?
If I wanted a language to enforce those rules, I’d be back to something
like:
class Hello {
public static void main(String [] args) {
System.out.println(“Hello, world!”);
}
}
I don’t. It’s fine if the language can enforce them – in Perl, I can do
things like ‘use strict’ or ‘use warnings’. In Ruby, I can simply grep
through my source files to make sure I haven’t stooped to using eval
anywhere I don’t absolutely have to.
So, if there was an UnboundMethod#bind! method, which would bind that
method to an object completely unrelated, I could choose not to use that
method. So could you. I don’t see how its very existence threatens that.
It’s a lot easier to ignore functionality you don’t need than it is to
find functionality you do need missing.
Module is
not a class,
Actually, Module is a class.
And
lastly, an instance method should not be treated as a loosely defined
function, nor should an object exhibit some foreign behaviour of some
arbitrary function, it totally violates encapsulation.
So do:
- instance_variable_set
- instance_variable_get
- send
- instance_eval
- Binding#eval
- extend
- class << foo
And, to a lesser extent:
- Modules as mixins (unless very carefully written, they’re touching
the same instance variable namespace) - class_eval
- include
- const_set
- define_method
Am I missing any?
If you wanted a language that enforced encapsulation, I say again, go
back to Java, or to C++. You’ll find encapsulation in Ruby is every bit
as much convention as it is in Perl.
The language makes it harder to violate that convention by accident,
that’s all. And if you want to enforce it, all you have to do is grep
through your codebase for cases of instance_variable_set, and similar
constructs.
Take a quick look at that first list. Have you really never used any of
those? Are you sure?
Your propositions
and suggestions translate into total chaos and anarchy, where any
identity could be shared among all members of the universe
I’m suggesting that it be possible to rebind a method.
Again: How is that worse than any of the above? You’re acting as if it
would destroy the fabric of the universe!
I was expecting opposition along the lines of “This would be difficult,
the way the Ruby interpreter is written.” Instead, I’m getting the kind
of response I would expect from the bad old Rails community: “You can’t
do that because we think it’s a bad idea, so we’re protecting you from
yourself.”
many objects are actors and actors are subjects with
responsibilities and behaviours, by which you classify them.
Right. I don’t know about you, but I classify them by their actual,
demonstrated behavior, not their ancestry.
Why, then, does the system for copying methods from one object to
another restrict by ancestry, and not by behavior?
Except Perl is not strictly procedural, and Javascript actually has a
very nice prototypal object system.This is is pure baloney. Perl was designed as such,
And Linux was designed as a terminal emulator. Quite literally. Look
where it is now.
Now who’s arguing aristocracy? Perl can never be OO, because it wasn’t
designed that way? Languages evolve.
The
same is true for JavaScript, which, metaphorically speaking, became of
old age only after ten years of it’s existence.
That only shows how little you know about JavaScript. It was actually
originally written as a dialect of LISP, and only later given a C-like
syntax to make the PHBs happy.
Because of its Lisp heritage, I can guess, but cannot prove, that it
always had closures, and always had functions as first-class objects.
Attempting to look at the history of object-oriented Javascript, you
find that it is mostly about people finding ways to express the kind of
object systems they want, using the powerful prototypal object system
that was already in place.
In fact, when it comes down to it, there’s no reason you can’t program
Javascript the way you program Ruby. It’s not difficult to write a sane
each() method, or add a class hierarchy (as opposed to prototypal
inheritance). However, it is much more difficult to write Ruby the way I
wrote Javascript, when I had to use it for more than just a web client,
and some things, as I’ve mentioned, are actually impossible. You speak
of “anarchy”, but it worked, and it worked very well.
Just let him have his pain!
Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
David M. wrote:
I fail to see how that’s more inherently anarchistic than:
- Re-opening classes at runtime
- Redefining methods, or whole classes, also at runtime
- Adding a method or mixing a module into just one instance
- All of the above with user input (eval)
- Doing no type checking whatsoever
- Overriding basic operators (make 2+2==5)
- Corrupt basic assumptions (make nil.nil? false) and crash
Indeed, all this can lead to anarchy and chaos, but that is your doing!
There must be a reason for redefining a class, if it is a subversion
than indeed it is anarchy, but how many creators sabotage their own
creation?. Language enforcing the rules does not mean that it should
stop you from making incorrect assumptions such as 2+2==5.
Statistically, type checking is not needed and mostly presents an
unnecessary clutter in the code with little if any benefit at all. And
what’s nil.nil - some devilish construct of yours?
Ruby’s strength is in what you’re calling “anarchy” – except when you
choose to call it “flexibility”.
I do not call Ruby anythingexcept OOPL from start to the end. And most
certainly all that you call inherently anarchistic above if used to
model the reality you are trying to reproduce with your design is power
unheard of in the traditional OOPLs.
You’ve certainly not done a good job of explaining or defining such
rules.
I did not invent nor made up those rules, they are spelt out in Booch,
and nicely packed in design patterns. You can adhere to these rules in
any language even assembler, it only is much harder to do so in
procedural languages. Besides, it is not so much about following these
rules as understanding them. Your misplaced comments about most of the
details you are bringing up in this discussion and most noticeably about
encapsulation show a serious deficit in this area on your part.
The fact that you see meritocracy in the same light as
aristocracy …
Show me where I said that.
Are not the following your words: “Except that Ruby enforces the
aristocracy with respect to which methods
belong to which classes”. I have gone to great length explaining the
difference between taxonomy that classifies things by its membership and
the other that takes into account the merits. The two are orthogonal and
do not mix as you are suggesting by attributing knighthood based on
behaviour (activity, methods, functions, processing) rather on ancestral
principles based on name or membership, as is known to us throughout the
history.
… It’s fine if the language can enforce them – in Perl, I can do
things like ‘use strict’ or ‘use warnings’…
Again you are mixing apples and oranges. Perl’s strict does not qualify
for encapsulation, orthogonality of aggregation or composition and
inheritance, for rule of favouring delegation over inheritance,… heck
I do not even know you understand what I am talking about! And I have no
time explaining or defining all this to you. For any OO programmer,
designer or analyst these are pure facts nobody questions or doubts any
more.
So, if there was an UnboundMethod#bind! method, which would bind that
method to an object completely unrelated, I could choose not to use that
method. So could you. I don’t see how its very existence threatens that.
You are a master of sabotage. I believe you do this only in forum
discussions and not to your code and creative processes, however if this
writing is a creative process, you must somewhat of an anarchist.
It’s a lot easier to ignore functionality you don’t need than it is to
find functionality you do need missing.
And what a generality is again this? I have not found it in any of the
pertinent methodologies discussed here. Most likely it is a convenient
concoction of yours for the sake of argument and no substance or merit
for that matter.
Actually, Module is a class.
Modularity packs abstractions into discrete units. Abstractions are
represented by classes. There is no way on the Earth to turn this
definition around. Namely a class can never be a module nor is module a
class as you are suggesting. Yes, you could make your own concoctions
but that ain’t gonna be OO!
Am I missing any?
As I have shown you above, a great deal and much more.
Have fun, cheers
On Wed, 2009-02-11 at 23:59 +0900, Reid T. wrote:
#!/usr/local/bin/ruby
puts “Rendering”
end
double zi = 0.0;
zr2 = zr * zr;
return 0;
Mandelbrot.newlet temp = zr * zi andfor y = -39 to 38 do
let _ = mandelbrot ();
print_endline “”;
System.Console.Write (Sys.time () - start_time)as info – pulled down and configured F# et al on my box.
compiled and ran the above code via Mono/F# – gets in the .08xxx range
fairly consistently – best run 0.075988
not very familiar with mono/et al — compiled with --optimize,
regularly gets in the .7xxx range, best 0.06399
On Wed, 2009-02-11 at 16:38 +0900, William J. wrote:
for y in -39...39 do end double zr = 0.0; zi2 = zi * zi; }puts
zr2 = zr * zr and print_endline "";print_endline “”;
System.Console.Write (Sys.time () - start_time)
as info – pulled down and configured F# et al on my box.
compiled and ran the above code via Mono/F# – gets in the .08xxx range
fairly consistently – best run 0.075988
Igor P. wrote:
- Overriding basic operators (make 2+2==5)
- Corrupt basic assumptions (make nil.nil? false) and crash
Indeed, all this can lead to anarchy and chaos, but that is your doing!
Exactly my point. So if I am allowed these things which can lead to
anarchy, why am I not allowed this other thing that can lead to anarchy?
Unless you mean they are “my doing” in that I wrote these capabilities
into Ruby, which I didn’t.
Language enforcing the rules does not mean that it should
stop you from making incorrect assumptions such as 2+2==5.
I’m talking about:
class Fixnum
alias_method :old_plus, :+
def +(other)
if self == 2 && other == 2
5
else
self.old_plus(other)
end
end
end
Statistically, type checking is not needed and mostly presents an
unnecessary clutter in the code with little if any benefit at all.
Ok, but what does that have to do with statistics? And does it not
strictly enforce the rules you seem to care about?
And
what’s nil.nil - some devilish construct of yours?
All objects respond to .nil?, and I’m surprised you made it this far in
a discussion of Ruby without knowing about this.
And, since classes are open, you can do this:
class NilClass
def nil?
false
end
end
Go ahead, type that into irb. Watch it crash on the very next command.
power
unheard of in the traditional OOPLs.
Traditional, like, I don’t know, Smalltalk? It seems just as reflective.
the other that takes into account the merits. The two are orthogonal and
do not mix as you are suggesting by attributing knighthood based on
behaviour (activity, methods, functions, processing) rather on ancestral
principles based on name or membership, as is known to us throughout the
history.
Except that which objects are allowed to have a certain method is
restricted entirely by ancestral principles.
I did not say that I saw a meritocracy in the same light as an
aristocracy – that’s something you’re inferring beyond what I actually
said. In this particular instance, Ruby is not a meritocracy.
… It’s fine if the language can enforce them – in Perl, I can do
things like ‘use strict’ or ‘use warnings’…Again you are mixing apples and oranges. Perl’s strict does not qualify
for encapsulation, orthogonality of aggregation or composition and
inheritance,
True enough. It is, however, an example of choice vs being forced to –
Perl’s strict mode will force me to declare variables. However, if I
don’t turn it on, the language will let me define variables as I like.
It is an unrelated feature, but Ruby does similar things – in 1.9, we
have send and public_send. If I want to be safe, and respect
encapsulation, I use public_send. If I don’t, I use send.
And I have no
time explaining or defining all this to you. For any OO programmer,
designer or analyst these are pure facts nobody questions or doubts any
more.
Clearly, I am an OO programmer. And clearly, I doubt them.
And clearly, you have time to write long, rambling responses that
don’t explain these principles. Argument from Authority?
So, if there was an UnboundMethod#bind! method, which would bind that
method to an object completely unrelated, I could choose not to use that
method. So could you. I don’t see how its very existence threatens that.You are a master of sabotage.
Nice ad-hominem. It doesn’t answer my question.
It’s a lot easier to ignore functionality you don’t need than it is to
find functionality you do need missing.And what a generality is again this? I have not found it in any of the
pertinent methodologies discussed here.
No, I consider it to be a self-evident truth, and something you see in
the design of Ruby.
For example: The ability to deliberately break encapsulation, and use
instance_eval, or send instead of public_send, etc, is something I’ve
certainly found useful in my own code. Tell me, have you never found a
use for these? Or even for class_eval?
How would you feel if someone removed them, because they felt they were
“sabotage”, that they violated the “purity” of Ruby’s OO system?
Certainly, you don’t want to just be using them all the time, because
that would lead to, as you said, “anarchy”. But when you need them, you
need them, and nothing else will do.
Actually, Module is a class.
Modularity packs abstractions into discrete units. Abstractions are
represented by classes. There is no way on the Earth to turn this
definition around. Namely a class can never be a module nor is module a
class as you are suggesting.
Modules are not classes, you are right. However, the global constant
Module is a class. That is what I meant.
Oh, and classes are modules. You can verify this for yourself:
Class.new.kind_of? Module
On Wed, Feb 11, 2009 at 03:42:34AM +0900, David M. wrote:
Robert K. wrote:
Just moving one method over is an ad
hoc solution which - when applied with only moderate frequency - will
give unreadable and thus unmaintainable code very soon.Again, I’m not seeing how this has any more potential for disaster than
duck typing or metaprogramming. Those have as much capacity for misuse.
They also both have great capacity for brilliant use, which is really
the
point. If I wanted a language that spent all its time holding my hand
and “protecting” me from myself, I’d use Python – not Perl and Ruby. I
have to wonder whether Robert’s preferences for language design might
not
be better suited to Python.
Note that I’m not saying anything bad about Python, per se. It’s just
that my programming preferences are not well suited to its “one right
way
to do it” philosophy.
called practical extraction and report language, but they decided
reports no longer belong in the core language. I know I’d be (slightly)
happier with PHP if templating wasn’t a part of the core language.
Really? Without templating, I’m not sure there’s a point to PHP.
It’s
basically Perl with a lot of the good stuff stripped out, and templating
added into the core language. In fact, with the growing ease of Ruby
use
for templating (via eruby, et cetera), PHP is rapidly becoming obsolete
in my world.
On Wed, Feb 11, 2009 at 04:20:19AM +0900, Igor P. wrote:
defended as a good OOPL, because it simply is not. It lacks so many
distinct from pyramid and geriatric hierarchical structures which are
the footprint for all the procedural languages. It takes to much effort
in procedural languages to account for that which they lack!
I’m not sure you’re clear on the definition of “orthogonal”.
. . . and OOP is actually very hierarchical in a lot of ways, at least
as
practiced in most languages – including, to a lesser extent, Ruby.
Igor P. wrote:
I did not invent nor made up those rules, they are spelt out in Booch,
and nicely packed in design patterns. You can adhere to these rules in
any language even assembler, it only is much harder to do so in
procedural languages. Besides, it is not so much about following these
rules as understanding them. Your misplaced comments about most of the
details you are bringing up in this discussion and most noticeably about
encapsulation show a serious deficit in this area on your part.
This is the most telling part of the voluminous stream of consciousness
you’ve been piping to comp.lang.ruby lately.
If you are committed to measuring everything in accordance with Booch,
you will find a whole legion of sinners here. Indeed, that I and others
keep wondering why you are not using Java or C++ makes sense in light of
this. For the most part Ruby goes duck-typing route, which is
fundamentally different than the route of Java or C++
patterns/methodologies you find in Booch.
Ruby is like Lisp in this regard. The flexibility is there to allow a
program to adapt to new information found only at runtime. A program is
able to rewrite itself according to the situation. This is the
essential power which made Lisp suitable for AI. It is impossible in
Java or C++, unless you greenspun a half-ass lisp interpreter to do what
you need (Greenspun's tenth rule - Wikipedia).
Take the example of delegation. There is no notion of Java-like
interfaces or C+±like classes of just pure virtuals. In Ruby a
delegate can have no relation, ancestry-wise, to the object it wraps.
It violates all the Booch rules: it should be outlawed!
Yet that’s the Ruby way: create an object and “let it ride”. Just start
quacking and go. To hell with the indoctrination ceremonies which
bestow permission to quack. Strange women lying in ponds distributing
swords is no basis for a system of government!
On Wed, Feb 11, 2009 at 10:23:23PM +0900, Igor P. wrote:
David M. wrote:
Ruby’s strength is in what you’re calling “anarchy” – except when you
choose to call it “flexibility”.I do not call Ruby anythingexcept OOPL from start to the end. And most
certainly all that you call inherently anarchistic above if used to
model the reality you are trying to reproduce with your design is power
unheard of in the traditional OOPLs.
In that case, I think you’re missing out on a lot of what Ruby has to
offer. There’s much more to it than object hierarchies.
do not mix as you are suggesting by attributing knighthood based on
behaviour (activity, methods, functions, processing) rather on ancestral
principles based on name or membership, as is known to us throughout the
history.
I think you must have completely misinterpreted what David said. He
said
that Ruby enforces what you call an “aristocracy” model in some
respects,
not that aristocracy and meritocracy are the same in any way.
… It’s fine if the language can enforce them – in Perl, I can do
things like ‘use strict’ or ‘use warnings’…
Again you are mixing apples and oranges. Perl’s strict does not qualify
for encapsulation, orthogonality of aggregation or composition and
inheritance, for rule of favouring delegation over inheritance,… heck
I do not even know you understand what I am talking about! And I have no
time explaining or defining all this to you. For any OO programmer,
designer or analyst these are pure facts nobody questions or doubts any
more.
Blessing provides encapsulation. The extreme simplicity of generating
lexical closures can provide both encapsulation and protection stronger
than the average Ruby object provides.
So, if there was an UnboundMethod#bind! method, which would bind that
method to an object completely unrelated, I could choose not to use that
method. So could you. I don’t see how its very existence threatens that.You are a master of sabotage. I believe you do this only in forum
discussions and not to your code and creative processes, however if this
writing is a creative process, you must somewhat of an anarchist.
I have a couple of points to make:
-
You’re obviously trying to slander the speaker rather than address
his points. That’s pretty offensive. -
If you want to keep using “anarchy” that way, you should probably
try making a case for “anarchy” being an inherently bad thing first.
Actually, Module is a class.
Modularity packs abstractions into discrete units. Abstractions are
represented by classes. There is no way on the Earth to turn this
definition around. Namely a class can never be a module nor is module a
class as you are suggesting. Yes, you could make your own concoctions
but that ain’t gonna be OO!
Let’s see what ri says:
---------------------------------------------------------- Class: Module
A +Module+ is a collection of methods and constants. The methods in
a module may be instance methods or module methods. Instance
methods appear as methods in a class when the module is included,
module methods do not. Conversely, module methods may be called
without creating an encapsulating object, while instance methods
may not. (See +Module#module_function+)
In the descriptions that follow, the parameter _syml_ refers to a
symbol, which is either a quoted string or a +Symbol+ (such as
+:name+).
module Mod
include Math
CONST = 1
def meth
# ...
end
end
Mod.class #=> Module
Mod.constants #=> ["E", "PI", "CONST"]
Mod.instance_methods #=> ["meth"]On Thu, Feb 12, 2009 at 12:17:26AM +0900, Julian L. wrote:
Yeah it’s macruby
Thanks. I’ll look into it.
Unfortunately, it seems rather Mac-specific, at first glance. I was
hoping for something a bit more portable.
On Wed, Feb 11, 2009 at 03:31:02AM +0900, Robert D. wrote:
That said I admit that one can write nice OO code in Perl with some discipline.
That’s sorta the point of the way Perl does things: one can write good
code if one knows what one is doing. One can write bad code in any
language if one does not know what one is doing. I’d rather use a
language that allows me to write good code and bad code, as I choose,
than a language that disallows code better than “acceptable” and tries
(but fails) to disallow bad code.
Robert D. wrote:
can implement MI in?
I’ve been thinking about it for a bit, and no, I’m really not. Aside
from (maybe) performance, what’s wrong with that implementation? After
all, Ruby has Module#ancestors, and the trick is older than dirt as the
various PATH variables in Unix.
Chad P. wrote:
added into the core language.
Very true. However, templating as a part of the core language is perhaps
one of the stranger parts of it, and is certainly something which is
ripe for abuse.
I think the main point to PHP now is sheer ubiquity – all the apps
already written in PHP, including some really impressive systems like
Drupal, and all the hosts which provide PHP out of the box, with the
programmer having to do nothing more complicated than FTP to deploy.
This also makes it dangerously quick to pick up – you’ve already got a
cheap and/or free website that lets you FTP in some static HTML files,
and you want to, say, add a hit counter. Copy and paste some snippet
into that HTML, change the extension to .php, and you’re now a PHP
developer.
Either way, that is sort of a representative sample – templating is
part of the core language. It’s really something that ought to be done
in a library – there’s more than one good templating system (haml,
anyone?), and you don’t want your entire program to be a template.
Perl used to be the same way, though. I think a recent release –
“recent” meaning “within the past five years or so” – they moved
“formats” out of the core language and into a library.
But I think that’s getting even more offtopic, so to bring it back to
Ruby… The one piece that really seems out of place is the Regex
syntax, but I can’t complain. Everything else, whether pure or not,
comes together in such a way as to make it easy to turn it into whatever
you need – Markaby is another example of why not to build templating
into the core language. Why put something in the core language when it
can be done in a DSL?