directly assigning to a field (was Java without OO)

java-programmer, directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>As-far-as-you're-concerned is OO completely defined by Smalltalk practices?
>
>If that's the case then please just write "Smalltalk OO" instead of "OO"
>
Hmm. The point of reading the references might not be to learn
Smalltalk, but to get a different perspective. After having used
Objective-C, C++, Python, and Java (not in that order) I think the
perspective of reading/using other languages is important. It
influences the programmer, and even suggests there may be better
languages to solve problems in than the ones they already use.

I don't think most Java programmers' investment in Java is so frail that
reading a Smalltalk book would shatter their world view. Perhaps it
would simply give them another perspective on their own class designs.
Same reason some people read editorals from multiple political viewpoints.

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>As-far-as-you're-concerned is OO completely defined by Smalltalk practices?
>
>If that's the case then please just write "Smalltalk OO" instead of "OO"
>
Hmm. The point of reading the references might not be to learn
Smalltalk, but to get a different perspective. After having used
Objective-C, C++, Python, and Java (not in that order) I think the
perspective of reading/using other languages is important. It
influences the programmer, and even suggests there may be better
languages to solve problems in than the ones they already use.

I don't think most Java programmers' investment in Java is so frail that
reading a Smalltalk book would shatter their world view. Perhaps it
would simply give them another perspective on their own class designs.
Same reason some people read editorals from multiple political viewpoints.

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
> Isaac Gouy wrote:
>
> >Thomas!
> >Isn't it the case that the standard Smalltalk solution for this task
> >is to split the responsibilities - the collection classes are given
> >responsibility for iterating over the list elements and holding an
> >accumulator value, and the client class is given responsibility for
> >implementing the accumulation?
> >
> > L inject: 0 into: [:sum :each | sum + each]
> >
> >Anyone whose used a functional programming language would recognise
> >the similarities to the fold function. Interesting that Smalltalk has
> >long provided support for a functional programming style.
> >
> >in Nice
> > foldLeft(L, (int sum,int each)=>{return sum+each;}, 0);
> >in Clean
> > foldl (+) 0 L
> >

> >Strange then that the functional language Clean provides a standard
> >function 'sum' and yet VisualWorks doesn't...
> >
> Personally, I was surprised as well, but realized that sum, min, max,
> and other things are easily implemented.

Serves me right for being sarcastic ;-)
More-like it just isn't worthwhile implementing "sum" in a general
framework - inject:into: and fold provide a much more generally useful
abstraction. The rationale for providing a specific implementation of
"sum" in Clean seems to be code optimization.

> Because everything is an
> object I can extended it at will.

You can extend it at will because you have the source code! It really
has nothing to do with "everything is an object" - Clean is functional
not OO, and yet I can change all kinds of things.

> Does Nice's sum, min,max functions allow it to work on Strings or only
> numbers?

Nice didn't have a "sum" function last-time I looked.

Clean (which I did mention) defines sum for any type that defines +
and zero. And happily, zero is *not* defined for String. Do you think
"sum" makes sense for something that isn't a number?

Clean max and min are defined for types that define ordering
functions, and happily, "<" is defined for String.

> How about BigDecimal and integers in the same collection?

Have you forgotten about Haskell integers already?
The same approach can be taken in Nice - I would guess that many other
"features" will be considered more important.

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote
-SNIP-
> Stroustrup might suggest that such a method is inappropriate inside
> Person because it doesn't defend the invariants. It has little to do
> with state, but belongs elsewhere. I guess we'd have to create another
> class that holds the multiple versions of getAThing() because it doesn't
> belong inside Person.
>
> Now, fetching a beer may be too-simple an example

Just too simplistic and vague a basis for reasoned discussion. Would
any OO designer really place every aspect of behaviour in a Person
object? Seems more likely that the design would factor behaviour into
separate Roles. (Buying alcohol isn't a role we'd give a 5 year
Person.)

> but if
> variant-defending-methods-only complicates something as simple as that
> and static typing complicates it even further, it doesn't sound like a
> pattern with promise.

Seems you mean "java 1.4 static typing" rather than "static typing".
Languages exist that implement both polymorphism and static type
checking.

java-programmer >> directly assigning to a field (was Java without OO)
"Thomas Gagn? <email***@***.com> wrote in message
news:email***@***.com...
> Jorn W Janneck wrote:
[snip]
> >well, the language i gave my examples in was not statically typed, and it
> >was not java, so really none of what you say above really applies, does
it.
> >
> Evidentally, not to your language.

neither does it apply to the topic of this thread, which, as my examples
show, is pretty orthogonal to issues of static typing. or java, its name
(java without oo) notwithstanding.

> Which is great. But being in
> c.l.j.a. it does apply. It wouldn't make sense for BOTH of us to be
> talking about different languages in c.l.j.a., would it?

you are having it backwards, though. the design principle which is under
discussion here, is a general one, which has no special connection to either
static typing or java. you occasionally tried to cast it in the light of
working around a shortdoming of either statically typed languages in general
or java in particular. in truth, it has pretty much nothing to do with any
specific programming language, so it would be intellectually appropriate to
discuss it that way. even in clja.

-- j

java-programmer >> directly assigning to a field (was Java without OO)
"Thomas Gagn? <email***@***.com> wrote in message
news:email***@***.com...
> Jorn W Janneck wrote:
>
> >if you like to quote graham, you will also know what he thinks about
"being
> >oo":
> > http://www.paulgraham.com/noop.html
> >
> >
> Great short essay. Thanks for pointing it out.
>
> He doesn't particularly idientify which of the 1 1/2 points he
> considered good (if 3 1/2 are bad), but a quick trip through them seems
> to indicate to me a distaste for OO ala C++/Java. The positive part of
> #4 can be applied to Smalltalk and *few* other OOPLs. #5 would
> generally apply to all OOPLs.

yeah, right, i am sure paul graham has also misunderstood "oo." i think you
should let him know.

btw, i actually do not think it's a very good essay, and i also do not share
you high opinion of graham's writings. i just thought that since you quote
him liberally yourself, you should not miss out on him fundamentally
disagreeing with you (actually, i am kinda surprised that you did not know
it, since his list of articles is rather short, and that is the only one
that deals directly with your pet subject "oo"). but, it seems, reading it
*the right way* brings things back into order, so that is fine.

-- j

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
> Isaac Gouy wrote:
>
> >As-far-as-you're-concerned is OO completely defined by Smalltalk practices?
> >
> >If that's the case then please just write "Smalltalk OO" instead of "OO"
> >
> Hmm. The point of reading the references might not be to learn
> Smalltalk, but to get a different perspective.

Replying to straightforward questions with koans is evasive. Evasions
don't make people interested in learning about Smalltalk.

*online* references are more accessible - Responsibility Driven Design
http://www.wirfs-brock.com/pages/resources/html/implementing_scenarios.html

> After having used
> Objective-C, C++, Python, and Java (not in that order) I think the
> perspective of reading/using other languages is important.

Humbly suggest that the last languages you should learn are Lisp or
Erlang - there's nothing there to challenge your opinions. Learn a
modern statically checked language - Nice, Clean, Haskell - learn how
to use polymorphism in a statically checked language. That will
challenge your opinions.

> I don't think most Java programmers' investment in Java is so frail that
> reading a Smalltalk book would shatter their world view.

I've just been trying to have you spell out exactly what you mean by
OO, since you justified putting 'sum' into the collection hierarchy
"Because it's OO."

There are many things we'd want to hold in a collection for which
'sum' is completely meaningless, so I'm struggling to understand in
what sense this design decision is OO.

java-programmer >> directly assigning to a field (was Java without OO)

Isaac Gouy wrote:

>><snip>
>>
>
>You can extend it at will because you have the source code! It really
>has nothing to do with "everything is an object" - Clean is functional
>not OO, and yet I can change all kinds of things.
>
True, but for different reasons. I can change the functionality of an
everything-is-an-object language by adding methods, which isn't far
simpler than modifying the source code. It's not like I have to change
the parser or the language's syntax.

><snip>
>
>Clean (which I did mention) defines sum for any type that defines +
>and zero. And happily, zero is *not* defined for String. Do you think
>"sum" makes sense for something that isn't a number?
>
I don't today. But I might tomorrow. The "sum" of the collection
#(apple orange) might be apple+orange. I may not need it today but
should be free to implement it tomorrow. Why should a language get in
the way?

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) "Jorn W Janneck" <email***@***.com> wrote

> > William Cook argued that these are complementary techniques - "classes
> > are able to express both ADTs and PDA (sic OO) syntactic form, but the
> > distinction between the two techniques still exists, and the practical
> > trade-offs are still operative." page 17
> >
> > http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf
>
> interesting paper, i will have a closer look

Did you come to any other conclusions?

Here's another example:
java.util.Collections
public static void sort(java.util.List list);

VW Smalltalk - SequenceableCollectionSorter
SequenceableCollectionSorter sort: aCollection

The aim of both methods is to take an ordered but unsorted collection,
and sort that collection in-place. The Java static method is defined
along with other static methods in a utility class; the Smalltalk
class-side method is defined (with 3 variants) in it's own utility
class.

In this case, we could copy the Smalltalk technique in Java - define a
new class responsible for sorting ordered collections. We could
approximate the Java technique in Smalltalk - instead of creating a
Sorter object with state, we could hold all the state in temporary
method variables and define all the sort functionality in a single
method.

Back to William Cook's paper - in one case, we are organising code
around object constructors; in the other, we are organising code
around operations.

It helps me be conscious of the differences and trade-offs, if we can
talk of the former as an OO style, and the latter as an ADT style.
Unfortunately it's difficult to get past, OO good, anything else bad.

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
> Isaac Gouy wrote:
> >You can extend it at will because you have the source code! It really
> >has nothing to do with "everything is an object" - Clean is functional
> >not OO, and yet I can change all kinds of things.
> >
> True, but for different reasons. I can change the functionality of an
> everything-is-an-object language by adding methods, which isn't far
> simpler than modifying the source code.

Some kinds of extension are easier with an OO style, and some kinds of
extension are harder.
Slide 24 - http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz

(Also William Cook's paper)

> >Clean (which I did mention) defines sum for any type that defines +
> >and zero. And happily, zero is *not* defined for String. Do you think
> >"sum" makes sense for something that isn't a number?
> >
> I don't today. But I might tomorrow. The "sum" of the collection
> #(apple orange) might be apple+orange. I may not need it today but
> should be free to implement it tomorrow. Why should a language get in
> the way?

Implement + and zero for "fruits", and "sum" would provide your answer
for this debased notion. The programming language doesn't get in the
way.
(You are free to define "sum" as convert-to-lemon if you wish)

Do the books you referenced advise forcing special-purpose-behavior
into general-purpose classes; or, instead, do they suggest creating a
special FruitCollection class (using some basic Collection class to
hold state)?

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
>
>
>>Isaac Gouy wrote:
>>
>>
>>>You can extend it at will because you have the source code! It really
>>>has nothing to do with "everything is an object" - Clean is functional
>>>not OO, and yet I can change all kinds of things.
>>>
>>>
>>>
>>True, but for different reasons. I can change the functionality of an
>>everything-is-an-object language by adding methods, which isn't far
>>simpler than modifying the source code.
>>
Of course, I meant to say, "..which IS far easier .."

>
>Some kinds of extension are easier with an OO style, and some kinds of
>extension are harder.
>Slide 24 - http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz
>
I don't understand how "Adding a new operation over all things" requires
OO languages adding a new method to every class. Why wouldn't adding a
method to Object take care of that?

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
>
>
>>Isaac Gouy wrote:
>>
>>
>>
>>>As-far-as-you're-concerned is OO completely defined by Smalltalk practices?
>>>
>>>If that's the case then please just write "Smalltalk OO" instead of "OO"
>>>
>>>
>>>
>>Hmm. The point of reading the references might not be to learn
>>Smalltalk, but to get a different perspective.
>>
>>
>
>Replying to straightforward questions with koans is evasive. Evasions
>don't make people interested in learning about Smalltalk.
>
You're too generous. The question didn't sound straightforward. I
apologize.

><snip>
>
>
>Humbly suggest that the last languages you should learn are Lisp or
>Erlang - there's nothing there to challenge your opinions. Learn a
>modern statically checked language - Nice, Clean, Haskell - learn how
>to use polymorphism in a statically checked language. That will
>challenge your opinions.
>
Noted.

>>I don't think most Java programmers' investment in Java is so frail that
>>reading a Smalltalk book would shatter their world view.
>>
>>
>
>I've just been trying to have you spell out exactly what you mean by
>OO, since you justified putting 'sum' into the collection hierarchy
>"Because it's OO."
>
>There are many things we'd want to hold in a collection for which
>'sum' is completely meaningless, so I'm struggling to understand in
>what sense this design decision is OO.
>

Perhaps I ought to. And perhaps I'm wrong. As a programmer I'm always
wondering what an object can do for me to make my problem easier to
solve. I think about what similar problems I might have in the future
that could be easily solved today. Adding #sum and #sum: to Collection
is one of them. Whether or not #sum is meaningless to collections of
flowers doesn't make a difference, because I won't try to #sum flowers,
or anything else unless it makes sense to. I'm the programmer. I know
when I have a collection of flowers and when I don't. If I have a
collection of numbers, or equations, or portfolios, or accounts, or
stocks, or anything else and I need to use #sum, I can.

This isn't unique to OO languages. Procedural abstractions tend to push
implementation details further down so that the code "higher-up"
contains more problem-domain code than "language-domain" code.
Iterators and for-loops are predominantly language domain and not
problem-domain. Burying the details of iterating inside a collection is
equivalent to the approaches of procedural abstraction or good
structured code.

Objects should be able to decide how they'll respond to messages.
Putting the responsibility for that response inside an object makes
better sense than having the responsibility outside. When it's inside
the object takes that behavior with it wherever it might be used. If
not implemented inside, then something else must travel around with the
object, and must somehow connect to the class, document how its
connected, and get a subsequent programmers attention to look there
first for extended class behaviors.

How many commands do we require end-users to enter to get our programs
to run? Is it better for end-users to /have/ to do more commands or
fewer? Why not consider the end-users of our objects and require less
from them--especially when we are often our own objects' end-users?

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

><snip>
>
>
>
>Did you come to any other conclusions?
>
See below.

>
>Here's another example:
> java.util.Collections
> public static void sort(java.util.List list);
>
> VW Smalltalk - SequenceableCollectionSorter
> SequenceableCollectionSorter sort: aCollection
>
>The aim of both methods is to take an ordered but unsorted collection,
>and sort that collection in-place. The Java static method is defined
>along with other static methods in a utility class; the Smalltalk
>class-side method is defined (with 3 variants) in it's own utility
>class.
>
Both are really constructed very similarly. But the biggest difference
between them is in why they exist. All ST Collection subclasses know
how to sort themselves. I can not do the same in Java's collection
hierarchy.

java.util.Collections.sort() can sort objects implementing all 24 of
List's methods, while Smalltalk's SequenceableCollectionSorter requires
only three methods be implemented.

>
>In this case, we could copy the Smalltalk technique in Java - define a
>new class responsible for sorting ordered collections. We could
>approximate the Java technique in Smalltalk - instead of creating a
>Sorter object with state, we could hold all the state in temporary
>method variables and define all the sort functionality in a single
>method.
>
Both are similar. If you /have/ to sort a collection of objects from
the outside the collection of objects both work. If you want to do the
sort in-place, both work, and I'm OK with that (I think).

>
>Back to William Cook's paper - in one case, we are organising code
>around object constructors; in the other, we are organising code
>around operations.
>
Both are fine (I think--I found his paper hard to read). What would
Cook say about a collection knowing how to sort itself?

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message
-SNIP-
> >Some kinds of extension are easier with an OO style, and some kinds of
> >extension are harder.
> >Slide 24 - http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz
> >
> I don't understand how "Adding a new operation over all things" requires
> OO languages adding a new method to every class. Why wouldn't adding a
> method to Object take care of that?

This isn't intended to be ad hominem:

Have you read the books you referenced?
Kent Beck's "Smalltalk Best Practice Patterns"
Simon Lewis' "The Art and Science of Smalltalk."

Do those authors give examples that would make you believe adding
methods to Object is good design in Smalltalk? Check those books and
let's see the examples.

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
> Isaac Gouy wrote:
-SNIP-
> >I've just been trying to have you spell out exactly what you mean by
> >OO, since you justified putting 'sum' into the collection hierarchy
> >"Because it's OO."
> >
> >There are many things we'd want to hold in a collection for which
> >'sum' is completely meaningless, so I'm struggling to understand in
> >what sense this design decision is OO.
> >
>
> Perhaps I ought to. And perhaps I'm wrong. As a programmer I'm always
> wondering what an object can do for me to make my problem easier to
> solve. I think about what similar problems I might have in the future
> that could be easily solved today. Adding #sum and #sum: to Collection
> is one of them. Whether or not #sum is meaningless to collections of
> flowers doesn't make a difference, because I won't try to #sum flowers,
> or anything else unless it makes sense to. I'm the programmer. I know
> when I have a collection of flowers and when I don't. If I have a
> collection of numbers, or equations, or portfolios, or accounts, or
> stocks, or anything else and I need to use #sum, I can.

Would you also allow the OrderedCollection>>addFirst: to be defined on
SortedCollection? You're the programmer. You know when you have an
OrderedCollection rather than a SortedCollection.

addFirst: is meaningless for a SortedCollection, so VW Smalltalk
defines SortedCollection>>addFirst: as 'self shouldNotImplement'

Why do you imagine 'shouldNotImplement' exists?

> This isn't unique to OO languages. Procedural abstractions tend to push
> implementation details further down so that the code "higher-up"
> contains more problem-domain code than "language-domain" code.
> Iterators and for-loops are predominantly language domain and not
> problem-domain. Burying the details of iterating inside a collection is
> equivalent to the approaches of procedural abstraction or good
> structured code.

Collection>>do: aBlock
That's abstract, so abstract that the implementation is a subclass
responsibility.

Collection>>inject: thisValue into: binaryBlock
That's abstract, but more special purpose than do: and defined in
terms of do:

(Jorn would suggest we should define this in it's own lexical context
to make clear that it only operates on a collection's public
interface.)

Collection>>sum ??? "total resulting from addition"
This is in the problem-domain of arithmetic. It's 2 steps away from
being an abstract iterator.
L inject: 0 into: [:sum :each | sum + each]

-SNIP rhetoric-

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
> Isaac Gouy wrote:
> >Here's another example:
> > java.util.Collections
> > public static void sort(java.util.List list);
> >
> > VW Smalltalk - SequenceableCollectionSorter
> > SequenceableCollectionSorter sort: aCollection

> Both are really constructed very similarly. But the biggest difference
> between them is in why they exist. All ST Collection subclasses know
> how to sort themselves.

This is either incorrect, or so vague as to be misleading.

All ST Collection subclasses know how to add their contents into a new
SortedCollection - only instances of SortedCollection 'know how to
sort themselves'.

-SNIP-

> >Back to William Cook's paper - in one case, we are organising code
> >around object constructors; in the other, we are organising code
> >around operations.
> >
> Both are fine (I think--I found his paper hard to read).

So you've changed your opinion?

Earlier, you didn't think OO was an organization principal, and in
several threads you've objected to utility classes (organising code
around operations).

(Maybe read the paper a couple more times?)

> What would
> Cook say about a collection knowing how to sort itself?
I'm not his spokesperson.

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>Thomas Gagn?<email***@***.com> wrote in message
>-SNIP-
>
>
>>>Some kinds of extension are easier with an OO style, and some kinds of
>>>extension are harder.
>>>Slide 24 - http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz
>>>
>>>
>>>
>>I don't understand how "Adding a new operation over all things" requires
>>OO languages adding a new method to every class. Why wouldn't adding a
>>method to Object take care of that?
>>
>>
>
>This isn't intended to be ad hominem:
>
>Have you read the books you referenced?
>Kent Beck's "Smalltalk Best Practice Patterns"
>Simon Lewis' "The Art and Science of Smalltalk."
>
>Do those authors give examples that would make you believe adding
>methods to Object is good design in Smalltalk? Check those books and
>let's see the examples.
>

Simon Lewis' book both cautions and encourages modifying system classes.
Another reference (I can't find right now) suggested adding to Object's
"testing" protocol to determine if an object might be able to do
something or be part of a class hierarchy without testing for the class
by name. I'll find the reference, else I suspect I wouldn't have tried it.

For instance (and I may find another way around it) I implemented a
mechanism allowing me to build and solve algebraic expressions using
standard Smalltalk syntax. Yes, the code

result := #apple + #orange

evalutes to apple+orange. It's proven valuable for working in mixed
currencies as well as arithmetic using weights and measures. The whole
thing made much easier by being able to determine if the object I'm
trying to add is a product (two expressions multipled together). It was
discouraged by more experienced programmers to test an object's
ancestory using #isKindOf:, but you probably already know why so I'll
spare you the details.

Perhaps because Smalltalk is dynamically typed and you can /attempt/ to
do anything with any object, it is not unusual to ask an object if it
#isSomething before proceeding. I found several in addition to my own
inside my VW image's Object's "testing" protocol.

For example, in Smalltalk I can ask if an object #isNil. Object defines
#isNil as returning false, while UndefinedObject returns true.

>
>
>

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...

Wouldn't you define a class Fruit and define operations on it?
Why are you messing with Symbol?

> It's proven valuable for working in mixed
> currencies as well as arithmetic using weights and measures.

Wouldn't you define a class Money that held both a value and currency?

> I found several in addition to my own
> inside my VW image's Object's "testing" protocol.

Unlike your new method sum: the testing methods don't require shouldNotImplement.

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
>
>Wouldn't you define a class Fruit and define operations on it?
>Why are you messing with Symbol?
>
I didn't think it made sense (early) to mess with String because I
didn't want to incur the overhead of testing = instead of ==. It didn't
make sense to create a class, Fruit or otherwise, because I wanted the
algebra to work within the syntax of Smalltalk literals. So that "z :=
2 * #x * #y" would result in z = 2xy. Then "z/#y" = "2y". Sybols are
treated simply as variables. Their names can be simple or words.
Expressions can be simplified by providing a dictionary of
equivalences. For instance, in=2.54cm would allow me to reduce an
exression using both inches and centimeters to one or the other. Best
of all, the expressions work (resolved or not) with or without the
equivalences. The expressions can be shown to a human without the
program really knowing what they are. It's proven valuable for dealing
with unit conversions I either know about ahead of time or don't know
about. If you order 2000 LB of sheet metal at $US3.17/LB and receive
1100lb, what is owed? Two different answers (both correct) are possible
depending if the equivalence, LB=100lb, is known.

>
>
>
>>It's proven valuable for working in mixed
>>currencies as well as arithmetic using weights and measures.
>>
>>
>
>Wouldn't you define a class Money that held both a value and currency?
>
Sure, but I want to store $US3.17/LB as an expression without having to
parse it. It's really easy if US and LB are variables and your system
knows to store products (3.17 * US) and divisions (3.17 * US) / LB, so
that later when we figure out (1.1 * LB) was delivered the resolver
knows it can reduce the expression by canceling out LB, leaving (3.17 *
US * 1.1), resulting in $US3.49.

>> I found several in addition to my own
>>inside my VW image's Object's "testing" protocol.
>>
>>
>
>Unlike your new method sum: the testing methods don't require shouldNotImplement.
>
So? When was the last time you got a type-error becuase you tried to do
math on flowers? I bet you haven't (not specifically flowers, but any
array, arrayList, vector, of non-numeric types) tried to do math on a
collection of objects math didn't make sense for. The big hint of a
variable being called flowerCollection might have suggested it was a bad
idea.

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org

java-programmer >> directly assigning to a field (was Java without OO) Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...

> It didn't
> make sense to create a class, Fruit or otherwise, because I wanted the
> algebra to work within the syntax of Smalltalk literals.

Why?

> >Wouldn't you define a class Money that held both a value and currency?
> Sure, but I want to store $US3.17/LB as an expression without having to
> parse it.

This seems to be the motivation that drove your decisions - how to
avoid parsing expressions? TGen is a fine Smalltalk parser generator.

The most obvious example of symbolic arithmetic in Smalltalk is the
Fraction class - why not use that as the model for your design?

Here are some more examples:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Jan.Bytesmiths-3006951317430001%40138.120.62.112

> >Unlike your new method sum: the testing methods don't require shouldNotImplement.
> So? When was the last time you got a type-error becuase you tried to do
> math on flowers?

shouldNotImplement is a statement about the design intention.

From what you've written, I have the impression that there are ideas
about OO design which are missing. It's not about type checking! It's
about creating cohesive classes with tightly related responsibilities
(remember CRC cards?)

Wirfs-Brock have been writing about this since Tektronix Smalltalk
http://www.wirfs-brock.com/pages/resources.html
http://www.wirfs-brock.com/pages/events_overview.html

java-programmer >> directly assigning to a field (was Java without OO) Isaac Gouy wrote:

>Thomas Gagn?<email***@***.com> wrote in message news:<email***@***.com>...
>
>
>
>>It didn't
>>make sense to create a class, Fruit or otherwise, because I wanted the
>>algebra to work within the syntax of Smalltalk literals.
>>
>>
>
>Why?
>
Smalltalk programmers already know algebra and Smalltalk. Why do I need
to create yet something else to parse?

>
>
>
>>>Wouldn't you define a class Money that held both a value and currency?
>>>
>>>
>>Sure, but I want to store $US3.17/LB as an expression without having to
>>parse it.
>>
>>
>
>This seems to be the motivation that drove your decisions - how to
>avoid parsing expressions? TGen is a fine Smalltalk parser generator.
>
>The most obvious example of symbolic arithmetic in Smalltalk is the
>Fraction class - why not use that as the model for your design?
>
I did. The base object is an expression specifying the operator (*/+-),
that has a left and right nodes. It has subclasses implementing the
operators that behave according to the operation attempted on them.

--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org