PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Autres forums > Forum Programmation & Conception > comp.lang.ruby > Re: Best practices for Ruby Meta-programming
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
Re: Best practices for Ruby Meta-programming

Réponse
 
LinkBack Outils de la discussion
Vieux 10/03/2008, 14h11   #1
Robert Dober
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Mon, Mar 10, 2008 at 4:06 AM, John Carter <john.carter@tait.co.nz> wrote:
If you use metaprogramming to make your code shorter you subtle point
might be quite valid, and yet you are too categorical for my taste.
Well factored metaprogramming might make your code more readable, do
not forget that
attr_reader e.g. is nothing less than MP.

FWIAC metaprogramming is here to do things at runtime and nothing else
in the world can replace it.
It is however always a valid question to ask if a redesign of the
application might allow us to get rid of MP, but in some cases it is
just not possible, look at some libraries as Ara's prototype or my
traits library.

You know sometimes it is just the right tool to use, *sometimes*.

Cheers
Robert



--
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

  Réponse avec citation
Vieux 10/03/2008, 17h41   #2
Todd Benson
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Mon, Mar 10, 2008 at 8:11 AM, Robert Dober <robert.dober@gmail.com> wrote:
> You know sometimes it is just the right tool to use, *sometimes*.
>
> Cheers
> Robert


100% agree.

My 2c on the topic...

I think of eval and other meta-programming tools in Ruby (funny, that
we use the same acronym for monkey-patching) like giving a Nascar to
your 16 year old kid to take his/her driver's license test in. In the
hands of a skilled driver, however, the car performs some kind of
magic. Or maybe a better analogy would be putting someone behind the
stick of a fighter jet with baby-safe control systems in place to make
things stable, and expect that person to be able to actually fly the
thing. They can at first, until they hit turbulence.

I'm still a kid in that respect, and try to avoid meta-programming as
much as possible (I actually use these features in Ruby quite often;
not much at all in other languages).

Todd

  Réponse avec citation
Vieux 10/03/2008, 21h41   #3
Robert Dober
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Mon, Mar 10, 2008 at 5:41 PM, Todd Benson <caduceass@gmail.com> wrote:
> On Mon, Mar 10, 2008 at 8:11 AM, Robert Dober <robert.dober@gmail.com> wrote:
> > You know sometimes it is just the right tool to use, *sometimes*.
> >
> > Cheers
> > Robert

>
> 100% agree.
>
> My 2c on the topic...
>
> I think of eval and other meta-programming tools in Ruby (funny, that
> we use the same acronym for monkey-patching) like giving a Nascar to

Sorry for the OT, but I am following Nascar for 20 years now and for
the first time *my* driver won the 500. Good old Rusty just never did
me that favor As none in Europe cares I just had to tell you, sorry
for the noise.
Robert

  Réponse avec citation
Vieux 11/03/2008, 05h31   #4
John Carter
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Mon, 10 Mar 2008, Robert Dober wrote:

> attr_reader e.g. is nothing less than MP.


I'd still be happier if I could flick a switch and see the
intermediate vanilla code that was generated.

> FWIAC metaprogramming is here to do things at runtime and nothing else
> in the world can replace it.


I suspect we've overloaded the term "meta-programming".

There are "programs that write programs".

There is a common subset of that ... "programs that instantiate
generic template code by substituting template variables with concrete
text."

If by meta-programming you mean one of the meanings above this line,
seeing a concrete vanilla ruby intermediate representation is
invaluable.

----------------------------------------------------------------------

If by meta-programming you mean one of the following, creating
concrete intermediate representations is harder..., but certainly not
impossible.

There are "programs that query & display the current run time state of
the program". (Profiling, debugging, coverage, memory profiling & leak
detection, object creation hotspot detection...)

There are _very_ hairy programs "that query the current run time state
of the program and modify the code 'on-the-fly' accordingly."

> You know sometimes it is just the right tool to use, *sometimes*.


Their are times and places where on-the-fly self-modifying code is
appropriate.

They are clearly marked on the map as "Here be Dragons".

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand


  Réponse avec citation
Vieux 11/03/2008, 12h01   #5
Robert Dober
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Tue, Mar 11, 2008 at 5:31 AM, John Carter <john.carter@tait.co.nz> wrote:
You are certainly right that MP is overused here, I have read slightly
different definitions of which I like best:
"Programming for the Programmer.

def attr_reader *atts
atts.each do |att|
define_method att do instance_variable_get "@#{att}" end
end
end

is definitely for the programmer, it also should rather run at runtime
than at compile time.

Robert


--
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

  Réponse avec citation
Vieux 11/03/2008, 22h40   #6
John Carter
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Tue, 11 Mar 2008, Robert Dober wrote:

> def attr_reader *atts
> atts.each do |att|
> define_method att do instance_variable_get "@#{att}" end
> end
> end
>
> is definitely for the programmer, it also should rather run at runtime
> than at compile time.


This topic is about Best Practices for Meta-Programming.

And you have just handed me a brilliant example of why human readable
intermediate representation _is_ Best Practice...


Hmm. Is
attr_read :foo
really equivalent to a plain getter?

define foo
@foo
end

The way I read your code it's equivalent to...

define foo
instance_variable_get "@foo"
end

Which is probably slower.

Either way the very fact we need to think about it illustrates the
value of human readable intermediate representations!

How about...

def make_getter( att)
"define #{att}
@#{att}
end
"
end

def Module.attr_read( *atts)
atts.each do |att|
self.class_eval( make_getter( att))
end
end

Note I have a bug in make_getter...

The class_eval failed for some mysterious reason, so I said...
puts make_getter("foo")
And got...
define foo
@foo
end

Oops! I see the problem...it should be...
def make_getter( att)
"def #{att}
@#{att}
end
"
end

And I get...
puts make_getter("foo")
And got...
def foo
@foo
end


Yip that worked.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand


  Réponse avec citation
Vieux 12/03/2008, 00h41   #7
Robert Dober
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Best practices for Ruby Meta-programming

On Tue, Mar 11, 2008 at 10:40 PM, John Carter <john.carter@tait.co.nz> wrote:
> On Tue, 11 Mar 2008, Robert Dober wrote:
>
> > def attr_reader *atts
> > atts.each do |att|
> > define_method att do instance_variable_get "@#{att}" end
> > end
> > end
> >
> > is definitely for the programmer, it also should rather run at runtime
> > than at compile time.

>
> This topic is about Best Practices for Meta-Programming.
>
> And you have just handed me a brilliant example of why human readable
> intermediate representation _is_ Best Practice...
>
>
> Hmm. Is
> attr_read :foo
> really equivalent to a plain getter?

Semantically yes, for the implementation
I have no idea, it is probably written in C. The point is what it is good for.
R.
>
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter@tait.co.nz
> New Zealand
>
>
>




--
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 19h56.


Édité par : vBulletin® version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières ©2000-2008
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,16192 seconds with 15 queries