Forum: Ruby proper use of classes

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-29 01:36
(Received via mailing list)
Greetings...

I'm continuing my learn-to-write-OO-Ruby journey. Had a recent bad
experience trying to convert a complex method to a class. The method
gets a lot of use in my program, and each time it needs to know a lot
about the environment outside itself. I found myself having to write a
ton of instance variable data into the class instance to get it to do
its job, before I called it each time, then read a few more back out to
get the results. It was awful. What had been a one line call was now
about 14 lines of code. Ack! I gave up and converted it back to a
method, which simply makes more sense. I could not find any
"class-magic" in this experience - just a lot of locked doors.

I now have three questions. I have read a number of people's accounts of
what classes are and how you build them, etc., etc., and no one seems to
address these matters at all well (or else I missed it):

1. HOW do you use a class?

I was assuming that since I couldn't pass data to an instance, after
creation, I have no option but to write data into its instance vars as
needed. Sometimes, it seems there simply is no other option.

But, is it approved practice to do something like

junk = MyClass.new( var_1...var_n ).mymethod

which creates an instance and calls a method which leaves its results in
some instance vars., then simple read the results with...but how?
there's no instance object! (Not that I can find, anyway.) That seems to
leave me only with this possibility:

myclass = MyClass.newMyClass.new( var_1...var_n )
myclass.mymethod
varA = myclass.var_whatever
etc....until I have all my results back out of the instance.

Compared to a simple method call, this seems designed to make me crazy
quickly. Is there a better way?

Then, to call the instance again, I have to write new data into its
instance vars. This simply looks like nonsense, unless one really needs
to have the encapsulation that an instance offers. Am I missing
something? Is this just the facts of life when using classes?

2. Is it accepted practice to simply create a new instance every time
the class is needed, thus setting the instance's state once, using it
with one or more method calls, then moving on to the next new instance?
It occurs to me that maybe Ruby's garbage collection would sweep the old
instance right up, knowing it won't be used again, but I don't know.

My nightmare case is a class which operates on an input record, but
differently each time, depending upon a number of factors in the
environment outside the class. I just can't see a graceful way to do
this. I'm struggling to see why I do OO programming at all in this case.

3. Finally, I'm still struggling with the "when do I make something a
class?" question. I'm surprised that this question is so unimportant or
its answer so obvious that no one much addresses it. Dave Thomas, in his
3rd ed. (I just upgraded, and its really nice!) finally gives two
sentences to the matter, which is way more than I can find anywhere
else: "Whenever you’re designing OO systems, a good first step is to
identify the things you’re dealing with. Typically each type of thing
becomes a class in your final program, and the things themselves are
instances of these classes."(p. 59)

I've been thinking only in terms of functions, things my program does,
and not things it works on or with. Both are relevant, clearly, and I'm
now out on a hunt for "things" that are more than functions. Maybe that
will help.

Anyone have any additional advice about "when to make something a
class?" The principle reasons I see are to achieve scope closure,
persistent state, and object duplication (multiple instances). Did I
miss anything important?

I come to the list with these questions only after days of struggle,
with lots of code, some of it a rather nasty experience (errors I've
never ever seen before!!!). The questions above are the ones I simply
have not been able to resolve, and any help offered will be gratefully
received.

Thanks,

Tom


The easier one (probably):

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-29 03:51
(Received via mailing list)
Hi --

On Thu, 29 Jan 2009, Tom Cloyd wrote:

> 1. HOW do you use a class?
>
> I was assuming that since I couldn't pass data to an instance, after
> creation, I have no option but to write data into its instance vars as
> needed. Sometimes, it seems there simply is no other option.

You can pass data to an instance:

   instance.some_method(data)

> But, is it approved practice to do something like
>
> junk = MyClass.new( var_1...var_n ).mymethod
>
> which creates an instance and calls a method which leaves its results in some
> instance vars., then simple read the results with...but how? there's no
> instance object!

What you've written here is similar to:

   upstring = String.new("David").upcase

or something like that, and it's perfectly legit, though you might
also want to grab the object separately:

   string = String.new("David")
   upstring = string.upcase

> (Not that I can find, anyway.) That seems to leave me only
> with this possibility:
>
> myclass = MyClass.newMyClass.new( var_1...var_n )

I don't quite get that line. What's newMyClass? (Or maybe it's
garbling again between our machines?)

> myclass.mymethod
> varA = myclass.var_whatever
> etc....until I have all my results back out of the instance.
>
> Compared to a simple method call, this seems designed to make me crazy
> quickly. Is there a better way?

I'm not sure I'm following. I guess the short answer is that there's a
ton of different patterns you can follow, depending on what you need
to do.

>
> My nightmare case is a class which operates on an input record, but
> differently each time, depending upon a number of factors in the environment
> outside the class. I just can't see a graceful way to do this. I'm struggling
> to see why I do OO programming at all in this case.

Normally you'd write a class in cases where you want more than one of
something. I'm not sure that's the case here. What exactly do you mean
by a class operating on an input record? Or, to go at it a different
way, what exactly is the flow of events that you want to handle? It
may be that you could use a class called InputHandler (or whatever),
and you'd do something like:

   ih = InputHandler.new(filename)
   fields = ih.parse_into_fields

A class is a generalization. So if what you're doing isn't general,
you may not need or want to model it in classes. If you're writing a
script to parse one particular file, there's quite likely no point
writing a generalized handler class.

I feel like I'm failing to get beyond the rather unhelpful "it
depends" level, but maybe prompt me with some further specifics....


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-29 13:18
(Received via mailing list)
David A. Black wrote:
> You can pass data to an instance:
>
>   instance.some_method(data)
Uh, yes. I had undervalued this possibility, about which I did know. I
suppose I could pass in an array of data describing some external state,
and parse it inside the class. Now, suddenly, I'm seeing a very
economical way to use classes.
>
>   upstring = String.new("David").upcase
>
> or something like that, and it's perfectly legit, though you might
> also want to grab the object separately:
>
>   string = String.new("David")
>   upstring = string.upcase
Yes, I think usually one would.
>
>> (Not that I can find, anyway.) That seems to leave me only with this
>> possibility:
>>
>> myclass = MyClass.newMyClass.new( var_1...var_n )
>
> I don't quite get that line. What's newMyClass? (Or maybe it's
> garbling again between our machines?)
Yeah, it's garble. Don't know why that happened.
>
>> myclass.mymethod
>> varA = myclass.var_whatever
>> etc....until I have all my results back out of the instance.
>>
>> Compared to a simple method call, this seems designed to make me
>> crazy quickly. Is there a better way?
Yeah - stuff the variables into an array, and access the array.
>
> I'm not sure I'm following. I guess the short answer is that there's a
> ton of different patterns you can follow, depending on what you need
> to do.
It's clear to me now that if I can pass in an array of data describing
external state, and can pull it back out by accessing a class instance
variable containing that array, transformed in some way by its having
passed through the class instance. Ah...I'm feeling much better now.
>
>> Then, to call the instance again, I have to write new data into its
>> instance vars. This simply looks like nonsense, unless one really
>> needs to have the encapsulation that an instance offers. Am I missing
>> something? Is this just the facts of life when using classes?
The "nonsense" remains, in that so far I'm just employing a method,
which happens to be formed as a class. There no obvious reason to have
formed it up as a class. Again I wonder - what's the point of using a
class? When do we do it? I can think of some applications, but mostly it
appears that mere methods are fine.
>> environment outside the class. I just can't see a graceful way to do
>   fields = ih.parse_into_fields
This looks like a method dressed up as a class. Why do this? I guess it
could make your root program simpler. Every time you want a new record,
you tickle the single class instance you have, and it spits out some
data. But, it quakes like a duck (method), so I have to say that's what
it is, disguised as a class. In the example, as given to this point,
there's no reason for the conversion to a class - none that I can see.
>
> A class is a generalization. So if what you're doing isn't general,
> you may not need or want to model it in classes. If you're writing a
> script to parse one particular file, there's quite likely no point
> writing a generalized handler class.
I have to agree. I reached that conclusion over the weekend, with some
disappointment. I started out some days ago wondering "why classes"? I
got some decent answers back, but have yet to really find an
application. Dave Thomas uses an example of a book story inventory
program, and creates a book class, one instance of which is created for
every book. So where does that leave us, I wonder? With a running
inventory program that has 50,000 little book objects bouncing around
inside? That makes no sense, to me. It certainly is an illustration of
using classes, but to me in no way illustrates the NECESSITY or even the
benefit of doing do. I keep thinking I'm missing something that everyone
else is seeing.

The technology of classes isn't the problem for me. It's the rationale.
I look at some of gems I use, and I see herds of classes. They make some
sense as containers for methods, certainly, but modules could do that,
or some clever naming scheme for set of classes which share some common
domain.

Maybe it's just an organizational thing. A class is way to create a
complex thing that looks and acts simple. That, of course, is a terrific
idea. But, again, mere methods do that quite nicely.

Somehow I'm not quite grasping the heart of the problem I'm having. One
more try - it's clear why sometimes one uses integers and other times
floats. I'm trying to get to that level of clarity regarding classes.
Right now, I appreciate the idea that I might do myClassInstance.a, then
*.b, , and so on, accessing various methods that are conveniently
grouped in my ClassInstance. AND that I might want to subclass this so
as to have a slightly different flavor of it.  It's also clear that I
might want to hold the state of some domain, while I go off and do other
things, returning at times to make use of that held state and any
associated methods. It all sounds like a nice idea.

I need to find some part of my code that cries out for this nice
concept, and so far I haven't. So far, I have a class that opens some
files and loads their contents in hashes. Once. And a similar one that
dumps the hashes back out. Once. A method would the job just as well.
Making those classes was just an exercise, it now seems.

I just looked over all my methods, in my current project. They're all
simply blocks of code that get used repeatedly. There's no need to hold
state. All state resides in the main program. Now, THAT - a main program
which manages a database modeled on a graph - I'll turn into a class, as
I might need to have multiple instances running simultaneously, and play
them off each other. THAT, I think, is the first clear need for a class
I've yet seen, in my little coding world. The absolute first.

Well, sorry for the digressive nature of my ruminations. I wander
because I AM a bit lost. Fascinated, but lost. Meanwhile, the code is
coming along nicely, so I can't really complain too much.

Thanks for your thoughts, David- they WERE helpful. If you have any
more, please pass them along. Your comments have always been helpful.

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-29 13:19
(Received via mailing list)
Hi --

On Thu, 29 Jan 2009, Tom Cloyd wrote:

>> something. I'm not sure that's the case here. What exactly do you mean
>> by a class operating on an input record? Or, to go at it a different
>> way, what exactly is the flow of events that you want to handle? It
>> may be that you could use a class called InputHandler (or whatever),
>> and you'd do something like:
>>
>>   ih = InputHandler.new(filename)
>>   fields = ih.parse_into_fields
> This looks like a method dressed up as a class.

"Class" and "method" are not commensurate. They're categorically
different; they don't stand in for each other. What I've got there is
a class, an instance of that class, and an instance method.

> Why do this? I guess it could
> make your root program simpler. Every time you want a new record, you tickle
> the single class instance you have, and it spits out some data. But, it
> quakes like a duck (method), so I have to say that's what it is, disguised as
> a class. In the example, as given to this point, there's no reason for the
> conversion to a class - none that I can see.

It feels to me like you've overthinking the issue. For one thing, it's
important to get back to *objects*. In other words, it's not a tug of
war between classes and methods; it's all about which objects will
help you the most. (Classes are objects, but that's secondary at the
moment.)

In my example, ih is an object that has state (it knows of a filename)
and behavior (it can parse the file into fields, whatever that may
mean). It's possible that I'd need an object that does not have state,
but that can parse files -- in which case, I might write a method on a
class or module (like YAML.load). But if I want my handler to remember
its filename, then a class is not appropriate, because I might have
more than one handler, or some other library that I load might want to
use the handler. The ability to create instances of a class, and
associate each instance with a file, means that the class itself
doesn't have to track who's using which file.

Again, it's really about objects, not classes. If I need three input
handlers, then I want a convenient way to create them. I could do this
each time:

   handler = Object.new
   handler.extend(SomeHandlerModule)
   handler.filename = filename
   handler.parse_into_fields

and so on, but a class is a shortcut way of doing something similar.

> book objects bouncing around inside? That makes no sense, to me. It certainly
> is an illustration of using classes, but to me in no way illustrates the
> NECESSITY or even the benefit of doing do. I keep thinking I'm missing
> something that everyone else is seeing.
>
> The technology of classes isn't the problem for me. It's the rationale. I
> look at some of gems I use, and I see herds of classes. They make some sense
> as containers for methods, certainly, but modules could do that, or some
> clever naming scheme for set of classes which share some common domain.

You can certainly use modules. The class Class is, in fact, a subclass
of the class Module, which means that in a certain sense, classes are
a specialization of module (basically, a module that can spawn
instances).

> Maybe it's just an organizational thing. A class is way to create a complex
> thing that looks and acts simple. That, of course, is a terrific idea. But,
> again, mere methods do that quite nicely.
>
> Somehow I'm not quite grasping the heart of the problem I'm having. One more
> try - it's clear why sometimes one uses integers and other times floats.

And Integer and Float are both classes :-)

> so far I haven't. So far, I have a class that opens some files and loads
> their contents in hashes. Once. And a similar one that dumps the hashes back
> out. Once. A method would the job just as well. Making those classes was just
> an exercise, it now seems.

Again, class and method are not warring concepts. Even if you write
classes, you still write methods -- and *every* method in Ruby resides
in either a class or a module.

> I just looked over all my methods, in my current project. They're all simply
> blocks of code that get used repeatedly. There's no need to hold state. All
> state resides in the main program. Now, THAT - a main program which manages a
> database modeled on a graph - I'll turn into a class, as I might need to have
> multiple instances running simultaneously, and play them off each other.
> THAT, I think, is the first clear need for a class I've yet seen, in my
> little coding world. The absolute first.

There's absolutely no technical imperative to write classes that you
don't need. It's not a higher plateau of programming; it's just a tool
for spawning objects.

One way to get a sense of how classes are used (and useful) is to
consider the Ruby language itself. In any language, you need to be
able to have multiple filehandles open. In Ruby, that need is
addressed by modeling each filehandle as an instance of File. The
class is, so to speak, the dispatch station, where requests for new
filehandles are fielded. But the class itself does not attach itself
to a particular file, since that would severely limit you.

In my Intro to Ruby training, I've got an exercise where you write a
program modeling a deck of cards. The exercise comes in several
flavors: write a Card class and Deck class, with Deck either
inheriting from Array or not, and write the whole program again
without defining any classes. It's all very valuable, and all the
techniques exposed by the exercise are important. As always, it comes
down to objects, and to what's the best way to launch the objects you
need.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-01-29 13:33
(Received via mailing list)
2009/1/29 Tom Cloyd <tomcloyd@comcast.net>:
> sense. I could not find any "class-magic" in this experience - just a lot of
> locked doors.
>
> I now have three questions. I have read a number of people's accounts of
> what classes are and how you build them, etc., etc., and no one seems to
> address these matters at all well (or else I missed it):
>
> 1. HOW do you use a class?

You might want to have a look at all those patterns around - they
should give you an idea how to use them.  You could start here:
http://c2.com/cgi-bin/wiki?WelcomeVisitors

> I was assuming that since I couldn't pass data to an instance, after
> creation, I have no option but to write data into its instance vars as
> needed. Sometimes, it seems there simply is no other option.
>
> But, is it approved practice to do something like
>
> junk = MyClass.new( var_1...var_n ).mymethod

That is a rather seldom idiom because usually you want your objects to
live longer.  Having said that, there is room for something like that
namely with complex calculations that need a lot of intermediate state
that you want to store in the instance.

> 2. Is it accepted practice to simply create a new instance every time the
> class is needed, thus setting the instance's state once, using it with one
> or more method calls, then moving on to the next new instance? It occurs to
> me that maybe Ruby's garbage collection would sweep the old instance right
> up, knowing it won't be used again, but I don't know.

Yes, that's accepted although one usually tries to keep instances for
longer.  In the command pattern you create an instance instead of
invoking a single method:

http://en.wikipedia.org/wiki/Command_pattern
http://c2.com/cgi-bin/wiki?CommandPattern

But even in this case the object lives rather long because the
calculation is typically complex and takes more time.

> My nightmare case is a class which operates on an input record, but
> differently each time, depending upon a number of factors in the environment
> outside the class. I just can't see a graceful way to do this. I'm
> struggling to see why I do OO programming at all in this case.

This smells like State or Strategy Pattern.

http://en.wikipedia.org/wiki/Strategy_pattern
http://en.wikipedia.org/wiki/State_pattern

> 3. Finally, I'm still struggling with the "when do I make something a
> class?" question. I'm surprised that this question is so unimportant or its
> answer so obvious that no one much addresses it. Dave Thomas, in his 3rd ed.
> (I just upgraded, and its really nice!) finally gives two sentences to the
> matter, which is way more than I can find anywhere else: "Whenever you're
> designing OO systems, a good first step is to identify the things you're
> dealing with. Typically each type of thing becomes a class in your final
> program, and the things themselves are instances of these classes."(p. 59)

There are a number of approaches to finding classes.  An easy one is
to identify nouns in your description of the problem.  Those are
candidate classes and verbs are candidate methods.  See the "tutorial"
section for more
http://users.csc.calpoly.edu/~dbutler/tutorials/wi...

> I've been thinking only in terms of functions, things my program does, and
> not things it works on or with. Both are relevant, clearly, and I'm now out
> on a hunt for "things" that are more than functions. Maybe that will help.

Yes, sounds as if this shift in perspective would help you. Rather ask
"what artifacts do I have in my problem domain" instead of "what needs
to be done"?

> Anyone have any additional advice about "when to make something a class?"
> The principle reasons I see are to achieve scope closure, persistent state,
> and object duplication (multiple instances). Did I miss anything important?

I guess with "scope closure" you mean "encapsulation". Persistence is
not mandatory for OO.

I found this book rather inspiring although it might not be the best
introductory text:
http://archive.eiffel.com/doc/oosc/

Kind regards

robert
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-01-29 14:47
David A. Black wrote:
> One way to get a sense of how classes are used (and useful) is to
> consider the Ruby language itself. In any language, you need to be
> able to have multiple filehandles open. In Ruby, that need is
> addressed by modeling each filehandle as an instance of File. The
> class is, so to speak, the dispatch station, where requests for new
> filehandles are fielded. But the class itself does not attach itself
> to a particular file, since that would severely limit you.

Good example. Similarly, methods which act on the filesystem, but don't
need to
maintain their own state, are class methods: e.g. File.exist?,
File.rename, File.delete

Another example you could consider is an XML parser. You could write
this as a standalone method in a module:

  result = XMLParser.parse(source)

That would parse the source from start to end in one operation. It might
return an object representing the results, or it could yield each
element to a block that you parse. But once the parsing is done, it's
done, and there's no need to remember anything.

One reason you might want to create an *instance* of a parser is to
remember options which will be re-used when parsing multiple documents:

  parser = XMLParser.new(:arrays => true, :strip_space => false)
  res1 = parser.parse(source1)
  res2 = parser.parse(source2)

A completely different reason is so that the parser object can be
attached to a particular document that you are parsing. This would allow
the parsing operation to be spread out over time, and you could ask it
when you like for the next tag - a "pull parser"

  parser = XMLParser.new(source)
  e1 = parser.next_element
  e2 = parser.next_element
  ...

Here, the object instance keeps a reference to the source object, and
keeps track of the parsing state (e.g. stack of open tags)

So the need to keep state is driven by the user's requirements. If you
don't need to keep state, then don't.

> I've been thinking only in terms of functions, things my program does,
> and not things it works on or with.

There is absolutely nothing wrong with this, and if you follow it to its
conclusion you will end up with functional programming, where every
output is a product of its inputs only. This is how many computer
science courses introduce programming.

For example, if you look at data structures in Erlang, generally you
pass in the old data structure as an argument and receive a new one as a
result:

    add_element(Element, Set1) -> Set2

There's no "set object" as such, just some data structure representing a
set, which is passed in and returned.

In Ruby, if you make an object representing a set, the first argument is
implicitly 'self', so there's no need to pass in Set1. Also, your method
may choose to return a new object, or to modify its own state.

Note that whilst you can demonstrate functional programming techniques
with Ruby, the language isn't really geared up to support them fully.
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-29 22:15
(Received via mailing list)
Robert Klemme wrote:
>> was awful. What had been a one line call was now about 14 lines of code.
>
>>
>> class is needed, thus setting the instance's state once, using it with one
> http://c2.com/cgi-bin/wiki?CommandPattern
>
>> matter, which is way more than I can find anywhere else: "Whenever you're
>
>
> http://archive.eiffel.com/doc/oosc/
>
> Kind regards
>
> robert
>
>
David, Brian, Robert - THANKS!

I'm fascinated to read your thoughtful responses, this morning - that,
and gratified. You each responded in different ways, and have offered me
considerable material to think on, and resources to explore. This is
precisely what I was hoping for. I think you "got it" that I'm genuinely
wanting to see this matter from the inside out, and your serious
responses, coupled with my coding adventures, will get the job done, I'm
sure.

My "overthinking" (I've been accused of that before on this list!) is
due to my background in philosophy. To my mind, making sense is the most
important thing we do with our minds, and it often requires a lot of
analytical probing, until all the meaningful dimensions of a problem
space are explored. Only then have you mapped the domain adequately.
That approach has often been my default method, with important things.
Not everyone's style, to be sure, but it is mine.

Again, my sincere gratitude for your taking the time to give me so much.
I will make good use of it!

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ae16cb4f6d78e485b04ce1e821592ae5?d=identicon&s=25 Martin DeMello (Guest)
on 2009-01-29 22:43
(Received via mailing list)
On Thu, Jan 29, 2009 at 6:03 AM, Tom Cloyd <tomcloyd@comcast.net> wrote:
> sense. I could not find any "class-magic" in this experience - just a lot of
> locked doors.

One thing that might help is an object to encapsulate the environment
that is passed to your method. For instance, a method that worked out
whether two particles, given by their initial positions and
velocities, would collide, would look something like

projectCollision(x1, y1, z1, vx1, vy1, vz1, x2, y2, z2, vx2, vy2, vz2)

As a first pass, we'd define a particle class

class Particle
  attr_accessor :x, :y, :z, :vx, :vy, :vz
  ...
end

and call our method with

projectCollision(particle1, particle2)

now particle1 and particle2 are objects of the class Particle, who get
their positions and velocities updated at the appropriate places in
the code. Your methods that deal with updating the particles'
positions and velocities need only pass particle objects around, and
the objects themselves act as slates to track changes to their
internal data. To a first approximation, I've found that using classes
to group and encapsulate function parameters is at least as useful a
refactoring as using classes to hold the functions themselves.

martin
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-30 00:14
(Received via mailing list)
Martin DeMello wrote:
>> was awful. What had been a one line call was now about 14 lines of code.
> projectCollision(x1, y1, z1, vx1, vy1, vz1, x2, y2, z2, vx2, vy2, vz2)
> projectCollision(particle1, particle2)
> martin
>
>
>
Wow. Martin that's a fascinating idea. Terrific notion. Gonna try to
make use of this. But just the idea is great for me to  know aout.

Thanks!

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-30 12:46
(Received via mailing list)
Hi --

On Fri, 30 Jan 2009, Tom Cloyd wrote:

> my background in philosophy. To my mind, making sense is the most important
> thing we do with our minds, and it often requires a lot of analytical
> probing, until all the meaningful dimensions of a problem space are explored.
> Only then have you mapped the domain adequately. That approach has often been
> my default method, with important things. Not everyone's style, to be sure,
> but it is mine.

I definitely would not discourage exploration of this kind. I'm 100%
in favor of fully understanding the techniques you're using, and
knowing exactly what Ruby is actually doing. But I still think you're
overthinking it :-)

By that I don't mean that you should stop trying to understand. It's
more that you're multiplying the complexity beyond what it actually
is, for example by positing a kind of substitution relation between
classes and methods.

That said, I think it's true that people learn and grapple with new
things in different ways. I tend to learn in what I think of as the
"Polaroid" style: I start with a breadth-first but very faint
perception of a technology, and gradually the whole picture comes into
view. It's actually kind of weird, because I can know that I'm going
to understand something by the end of the day, and yet not be able to
accelerate the process.

By the same token, I think that what I call "overthinking" is, as you
say, your way of getting there. I just wanted to clarify the point
that I'm not discouraging a deep understanding, just sounding the
buzzer as you cross the invisible line between the road and the
shoulder :-)


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-31 10:03
(Received via mailing list)
David A. Black wrote:
>> it" that I'm genuinely wanting to see this matter from the inside
>
> I definitely would not discourage exploration of this kind. I'm 100%
> in favor of fully understanding the techniques you're using, and
> knowing exactly what Ruby is actually doing. But I still think you're
> overthinking it :-)
>
> By that I don't mean that you should stop trying to understand. It's
> more that you're multiplying the complexity beyond what it actually
> is, for example by positing a kind of substitution relation between
> classes and methods.
Ah. Now I understand. I actually never positing that at all. I didn't
clarify things when you implied that a while back. Was too busy trying
to keep up with the new material in the developing thread. My problem
was simply that as I was trying to introduce classes into my project
code, I didn't know when I really SHOULD create a class. I had gotten
the impression somewhere that major methods should virtually always be
reconceptualized as classes. I didn't arrive at that notion by thinking.
I'd given up on that, as I didn't have enough material to work with.

But, that perception didn't really make a lot of sense. Still, I
couldn't find any explicit guidance anywhere regarding the fundamental
question I kept asking: WHEN is it the thing to do to make a class? I
did find those two sentences in Thomas (3rd ed) - but that's sparse
pickins, and I didn't find them until AFTER my weekend disaster in which
I spend a pile of time converting a complex method into a class, getting
completely exasperated with the experience, and converting it back. So,
I wasn't overthinking at all. I was mis-perceiving, in the presence of
an absence (ha!) - an absence of clear guidance about the
WHEN-do-classes issue. The best sense I could make of things was that
"big stuff oughta be classes" (bad idea). I didn't yet "get it"
(understatement).
>
> That said, I think it's true that people learn and grapple with new
> things in different ways. I tend to learn in what I think of as the
> "Polaroid" style: I start with a breadth-first but very faint
> perception of a technology, and gradually the whole picture comes into
> view. It's actually kind of weird, because I can know that I'm going
> to understand something by the end of the day, and yet not be able to
> accelerate the process.
This is one of two learning styles that has been documented among
programmers, leading to the realization that programming needs to be
taught simultaneously in two quite different ways - the left-brained
folks need linear progressions and the right-brained folks need
gradually emerging patterns, just as you have described for yourself.
>
> By the same token, I think that what I call "overthinking" is, as you
> say, your way of getting there. I just wanted to clarify the point
> that I'm not discouraging a deep understanding, just sounding the
> buzzer as you cross the invisible line between the road and the
> shoulder :-)
Hey, I can usually use all the warning calls anyone cares to give me,
believe me!

In any case, this thread has been remarkably useful to me, in my
tortured journey toward a more classy (uhem) way of programming.

BTW, I was puzzled for years by the mathematical notion of a function.
It just eluded me. Baffled me. Then, as I was learning to program in
Fortran, years ago, I began to wonder if there was any relation between
Fortran functions (hope you know a little Fortran) and mathematical
functions. Of course, there is. Fortran functions was no problem at all
to grasp, and once I realized they were just another way of expressing a
mathematical function (or perhaps I should say that a math function can
be expressed as a Fortran function, and in fact that was what they were
for), I was seriously rageful. I couldn't understand why something so
easy had been made so hard (for me) in math. classes. I'm still a little
pissed about that. There's little excuse for that kind of stupid
teaching.

So, we must attend to our students, and how it is they REALLY learn. I
like to think that we're better at that now than we used to be.

t.
>
>
> David
>


--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9e2504e0b74e5384af09ce8a660afac4?d=identicon&s=25 Pascal J. Bourguignon (Guest)
on 2009-01-31 10:50
(Received via mailing list)
Tom Cloyd <tomcloyd@comcast.net> writes:
> did find those two sentences in Thomas (3rd ed) - but that's sparse
> pickins, and I didn't find them until AFTER my weekend disaster in which
> I spend a pile of time converting a complex method into a class, getting
> completely exasperated with the experience, and converting it back. So,
> I wasn't overthinking at all. I was mis-perceiving, in the presence of
> an absence (ha!) - an absence of clear guidance about the
> WHEN-do-classes issue. The best sense I could make of things was that
> "big stuff oughta be classes" (bad idea). I didn't yet "get it"
> (understatement).

First you write a problem statement.
Then you identify the important words in it.
Nouns will become classes.
Verbs will become methods.
(approximatively).

The idea is that what has nouns in natural language are the objects
that have some stability in the real world, and what has verbs are the
actions.


Of course, you can have reification of the actions or the
associations, when you start to speak about verbs (notice that "verb"
is a noun, not a verb).

    For example, when you write:

    (def m(x)
      (2 * x)
    end)

    you actually instantiate an object of the class Method:

    (Object . method "m")
    --> #<Method: Class(Object)#m>

    but you do that only when you're talking at a meta-level, here it's
    the level of the Ruby language, not that of your problem domain.


Instead of reifying the "big stuff", you should rather try to reify
the _stable_ stuff.  A Person is something that is table, from her
birth to her death.  On the other hand, eating, sleeping, working,
reproducing, breathing, are temporary actions.  There even are actions
that cannot be done during all the life time. For example, a baby
Person has no walk method.  This method is programmed during the first
few years.


Objects encapsulate state and methods.

When your problem domain (cf the problem statement) considers a Person
only in her relations with the surrounding world, then the methods of
a Person will be Ruby methods.  You won't need to reify these methods.

On the other hand, if your problem statement is to implement a Person
simulator, then it's possible that the methods of a Person need to be
reifed, so you can add, change and remove these methods.  Imagine
having to write a Person simulator that starts in the baby state, and
that should evolve a walk method.  In this case, you could have a
MotorMethod class, and a Walk subclass, as well as classes such as
Muscle, Bone, Nerve, etc.  But these kind of classes would be named in
the problem statement (at least latently, sometimes problem statements
are brief).
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-01-31 11:00
(Received via mailing list)
On 31.01.2009 10:02, Tom Cloyd wrote:
> BTW, I was puzzled for years by the mathematical notion of a function.
> It just eluded me. Baffled me. Then, as I was learning to program in
> Fortran, years ago, I began to wonder if there was any relation between
> Fortran functions (hope you know a little Fortran) and mathematical
> functions. Of course, there is. Fortran functions was no problem at all
> to grasp, and once I realized they were just another way of expressing a
> mathematical function (or perhaps I should say that a math function can
> be expressed as a Fortran function, and in fact that was what they were
> for), I was seriously rageful.

IMHO there is an important distinction though which makes Fortran
functions a bad example: mathematical functions usually do not have side
effects, i.e. they can be completely described in terms of input and
output.  I view them as a relationship (or call it a mapping) which
assigns particular output values to particular input values.  If I'm not
mistaken, a Fortran function can have side effects on arguments (and
probably global variables).  A closer analogy are functions in - you
guessed it - functional languages.

Kind regards

  robert
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-31 22:17
(Received via mailing list)
Robert Klemme wrote:
>> rageful.
> Kind regards
>
>     robert
>
>
Robert - I absolutely agree, and I can to that (or THOSE)
understanding(s) in my first pass through grad. school. The idea of a
function being a rule that associates two sets of numbers seems to me
the most useful. However, the initial breakthrough for me was to see a
function as a little program - a process: put something in, get
something out. So easy. For some reason, that view it escaped me
throughout high school, etc. (I was a writer, not a calculator!).

Thanks for your thoughts, as always. I always enjoy what you have to
say!

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-01-31 22:19
(Received via mailing list)
Pascal J. Bourguignon wrote:
>> couldn't find any explicit guidance anywhere regarding the fundamental
>>
>
>
> the _stable_ stuff.  A Person is something that is table, from her
> only in her relations with the surrounding world, then the methods of
> are brief).
>
>
Pascal,

This is a simply lovely exposition. I'll add it to the other in this
very helpful thread. And, I'm returning to my code, with these thoughts
in mind, to see what I can learn.

Thanks for taking the time to make these things so clear. Much
appreciated.

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D1309ef77561e3cdf0ddcab60b244e52?d=identicon&s=25 Mike Stephens (aspirer)
on 2009-02-01 00:00
An attractive aspect of Ruby is how it is usually presented as agnostic
- you can use it in an object oriented style or you can choose
functional or procedural styles. So if you like to think in terms of
procedures instead of objects you can still sit at the same tables as
other Ruby programmers. Having said that, I would guess that any
procedure can be re-represented in terms of objects and your thinking
should move in that direction over time to align with the essence of the
language.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-01 04:42
(Received via mailing list)
Hi --

On Sun, 1 Feb 2009, Mike Stephens wrote:

> An attractive aspect of Ruby is how it is usually presented as agnostic
> - you can use it in an object oriented style or you can choose
> functional or procedural styles. So if you like to think in terms of
> procedures instead of objects you can still sit at the same tables as
> other Ruby programmers. Having said that, I would guess that any
> procedure can be re-represented in terms of objects and your thinking
> should move in that direction over time to align with the essence of the
> language.

I particularly like the way the functional/procedural programming
style is engineered to work with the OO style, in the sense that
functional-style method calls are actually calls to private methods --
and privacy is enforced by having to omit the explicit receiver... so
that methods like puts, which are private methods of Object, can be
called at any point in the program, since self is always an instance
of a descendant of Object.

In some respects, this is perhaps the most productive use of private
methods in Ruby, since the privacy is not strictly enforced. If it did
nothing else than provide a way to integrate the functional style into
the OO architecture, it would still be worth it.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2009-02-01 09:38
(Received via mailing list)
On Sat, Jan 31, 2009 at 11:00 PM, Mike Stephens <rubfor@recitel.net>
wrote:
> An attractive aspect of Ruby is how it is usually presented as agnostic
> - you can use it in an object oriented style or you can choose
> functional or procedural styles. So if you like to think in terms of
> procedures instead of objects you can still sit at the same tables as
> other Ruby programmers. Having said that, I would guess that any
> procedure can be re-represented in terms of objects and your thinking
> should move in that direction over time to align with the essence of the
> language.
>

The power of Ruby does not come from its object-orientation alone -
how many times do we really use polymorphism or inheritance? Yet I bet
most of us use #select, #map, blocks and literal regular expressions
in almost every program we write. I certainly do.

I personally see Ruby as an elegant melding of Lisp, Smalltalk and
Perl - functional, object-oriented and pragmatic, evenly balanced and
working in harmony.

I recommend every programmer should read
http://csis.pace.edu/~bergin/patterns/ppoop.html as an (unintentional)
precautionary tale against the over-zealous application of
object-oriented design,

Regards,
Sean
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-01 12:54
(Received via mailing list)
Hi --

On Sun, 1 Feb 2009, Sean O'Halpin wrote:

>
> The power of Ruby does not come from its object-orientation alone -
> how many times do we really use polymorphism or inheritance? Yet I bet
> most of us use #select, #map, blocks and literal regular expressions
> in almost every program we write. I certainly do.

At the same time, though, I'd say that object orientation per se
doesn't depend on polymorphism and inheritance. To me it's the
convergence back onto the sending-msgs-to-objects paradigm that's at
the heart of it (though I don't put that forth as a CS-ly correct
characterization, just my sense of it).

On the third hand... :-) there's that functional style of calling
methods in Ruby, though it's also OO under the hood of course.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
Ef3aa7f7e577ea8cd620462724ddf73b?d=identicon&s=25 Rob Biedenharn (Guest)
on 2009-02-01 21:47
(Received via mailing list)
On Feb 1, 2009, at 6:54 AM, David A. Black wrote:

> On the third hand... :-) there's that functional style of calling
> methods in Ruby, though it's also OO under the hood of course.
>
>
> David


I think you mean:  "On the gripping hand..."

(If you read Larry Niven, that is ;-)

-Rob

Rob Biedenharn    http://agileconsultingllc.com
Rob@AgileConsultingLLC.com
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-02-02 15:51
(Received via mailing list)
On 1 Feb 2009, at 11:54, David A. Black wrote:
>>> other Ruby programmers. Having said that, I would guess that any
>> most of us use #select, #map, blocks and literal regular expressions
>> in almost every program we write. I certainly do.
>
> At the same time, though, I'd say that object orientation per se
> doesn't depend on polymorphism and inheritance. To me it's the
> convergence back onto the sending-msgs-to-objects paradigm that's at
> the heart of it (though I don't put that forth as a CS-ly correct
> characterization, just my sense of it).

I like to think of Ruby as being the English of programming languages.
It's got a large and flexible vocabulary that makes it very powerful
to work with, but unlike Perl or Lisp or C it's also a very easy
language to get to grips with.

I'm particularly keen on the loose and pragmatic approach to OO. Being
able to open classes and objects at will makes it very easy to
specialise them for a specific project. And as for inheritance
hierarchies, there's much less pressure to build these rigid and
gargantuan frameworks than in certain mainstream languages.

As for the functional aspect, I tend to even forget I'm using a
functional style because message sending is so pervasive that chaining
higher-order functions is the obvious way to solve many problems.

Oh, and best of all Ruby's fun to code in :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2009-02-02 16:08
(Received via mailing list)
> Oh, and best of all Ruby's fun to code in :)

Right, as long as everyone remembers not to scuff their knees on the
playground sand jumping from the jungle gym :-)

Todd
0c00d644de3b8bb2f655908c79af25a5?d=identicon&s=25 Matt Lawrence (Guest)
on 2009-02-02 22:13
(Received via mailing list)
On Mon, 2 Feb 2009, Eleanor McHugh wrote:

> I like to think of Ruby as being the English of programming languages. It's
> got a large and flexible vocabulary that makes it very powerful to work with,
> but unlike Perl or Lisp or C it's also a very easy language to get to grips
> with.

English does not borrow from other languages. English follows other
languages into dark alleys, knocks them over, and rifles through their
pockets for loose vocabulary.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-02 23:37
(Received via mailing list)
On 2 févr. 09, at 16:11, Matt Lawrence wrote:

>
> -- Matt
> It's not what I know that counts.
> It's what I can remember in time to use.
>

English, unlike other languages, is very consistent and
straightforward.  For example,  the plural of boot is boots and the
plural of foot is foots.  Ok.  Maybe I need a better example.

1100
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-03 02:01
(Received via mailing list)
On Mon, Feb 2, 2009 at 4:11 PM, Matt Lawrence <matt@technoronin.com>
wrote:

>
> I like to think of Ruby as being the English of programming languages. It's
>> got a large and flexible vocabulary that makes it very powerful to work
>> with, but unlike Perl or Lisp or C it's also a very easy language to get to
>> grips with.
>>
>
> English does not borrow from other languages. English follows other
> languages into dark alleys, knocks them over, and rifles through their
> pockets for loose vocabulary.


Actually, I'd say quite the opposite, English vocabulary is the result
of a
long history of the English language being raped by the Languages of
whatever happened to be the latest invaders. Those words were injected
into
the language rather than being pick-pocketed.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 Gary Wright (Guest)
on 2009-02-03 02:09
(Received via mailing list)
On Feb 2, 2009, at 8:00 PM, Rick DeNatale wrote:
> Actually, I'd say quite the opposite, English vocabulary is the
> result of a
> long history of the English language being raped by the Languages of
> whatever happened to be the latest invaders. Those words were
> injected into
> the language rather than being pick-pocketed.


I'd say that English is more like the Borg.  Resistance is futile.
You will be assimilated.

Gary Wright
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-03 04:35
(Received via mailing list)
Juan Zanos wrote:

>> English does not borrow from other languages. English follows other
>> languages into dark alleys, knocks them over, and rifles through
>> their pockets for loose vocabulary.
>
> English, unlike other languages, is very consistent and
> straightforward.  For example,  the plural of boot is boots and the
> plural of foot is foots.  Ok.  Maybe I need a better example.

"Okay" is a real word. "OK" is an historical bacronym. (The published
dictionaries have this one wrong.) Okay means "emphatic yes" in Wolof,
one of
the languages English... knocked over. "Banana" and "hippie" come from
the same
source...
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-02-03 04:48
(Received via mailing list)
Why does this matter?

Sent from my iPhone
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-03 05:08
(Received via mailing list)
Julian Leviston wrote:
> Why does this matter?

>>> Ok.  Maybe I need a better example.

>> "Okay" is a real word.

Following up on a joke - someone needed a better example. (-:
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2009-02-03 18:48
(Received via mailing list)
Julian Leviston wrote:
> Why does this matter?
>
> Sent from my iPhone

Ah, the irony.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-03 19:10
(Received via mailing list)
Joel VanderWerf wrote:
> Julian Leviston wrote:
>> Why does this matter?
>>
>> Sent from my iPhone
>
> Ah, the iRony.

I fixed it for you!
D15a45a973443d4562051eb675b60474?d=identicon&s=25 Tom Cloyd (Guest)
on 2009-02-04 07:59
(Received via mailing list)
Juan Zanos wrote:
>> languages into dark alleys, knocks them over, and rifles through
>
> 1100
>
>
>
I propose that we allow 'foots'. to be a subclass of foot - for those of
us who secretly wish English had the lucidity of Spanish, or, if we dare
to dream, Ruby....

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This topic is locked and can not be replied to.