Collection API's VI (was: OO-Process - Proof [T]) 
Author Message
 Collection API's VI (was: OO-Process - Proof [T])

(addendum)

Further, if most of the operations overlap in Smalltalk
collections, then why are there differences? Are
the differences truly mutually exclusive? Being
only one class at a time assumes that the *differences*
between collection type A and collection type B
are mutually exclusive, no?

If you brag that there is a lot of overlap,
then why have ANY sub-divisions of collections
to begin with?

What is so special and mutually exclusive
about the few operations that DON'T overlap
between collection types/classes?

-T-



Wed, 14 Apr 2004 10:46:30 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

> then why have ANY sub-divisions of collections

The real answer to this and a lot of your other questions and
arguments is that if we did things your way most software would be
intolerably slow.  Since you aren't a real programmer you might have
never encountered any situations where a program took thousands of
times longer than it should have, but most people on these forums know
what I mean.


Wed, 14 Apr 2004 20:11:11 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

> (addendum)

I do not know what this is an addendum too so I can only answer what is
here.

Quote:

> Further, if most of the operations overlap in Smalltalk
> collections, then why are there differences? Are
> the differences truly mutually exclusive? Being
> only one class at a time assumes that the *differences*
> between collection type A and collection type B
> are mutually exclusive, no?

> If you brag that there is a lot of overlap,
> then why have ANY sub-divisions of collections
> to begin with?

> What is so special and mutually exclusive
> about the few operations that DON'T overlap
> between collection types/classes?

You seem to be missing the entire concept of polymorphism.  Just because
the methods (operations overlap) in their usage, does not mean they
overlap in their implementation.  Nor their outcome.  Take for example
add: for List and for Set.  The set implementation must check for
duplicates but the list need not.  Also the outcome is different.

Set new add: 1; add: 1 add: 1       will end up with only one item.

List new add: 1; add: 1 add: 1    will end up with 3 items

- Show quoted text -

Quote:

> -T-



Thu, 15 Apr 2004 00:22:54 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:


> > (addendum)

> I do not know what this is an addendum too so I can only answer what is
> here.

> > Further, if most of the operations overlap in Smalltalk
> > collections, then why are there differences? Are
> > the differences truly mutually exclusive? Being
> > only one class at a time assumes that the *differences*
> > between collection type A and collection type B
> > are mutually exclusive, no?

> > If you brag that there is a lot of overlap,
> > then why have ANY sub-divisions of collections
> > to begin with?

> > What is so special and mutually exclusive
> > about the few operations that DON'T overlap
> > between collection types/classes?

> You seem to be missing the entire concept of polymorphism.  Just because
> the methods (operations overlap) in their usage, does not mean they
> overlap in their implementation.  

The API's are supposed to *hide* implimentation details. If
you divide them by implementation, then you are overemphazing
implementation. This is counter to OO philosophy, isn't it?

Quote:
> Nor their outcome.  

Different outcome == different interface

Quote:
> Take for example
> add: for List and for Set.  The set implementation must check for
> duplicates but the list need not.  Also the outcome is different.

> Set new add: 1; add: 1 add: 1       will end up with only one item.

> List new add: 1; add: 1 add: 1    will end up with 3 items

That means you cannot do both set and list operations on
the same node or sets of nodes at the same time.
This is counter to real world needs where one user
may need one view and another a different view.
(This may not apply to adding elements, but
it could apply to other operations.)

Also, if one switches from a set to a list (or versa)
because they need more functionality, then the using
code is broke if it works differently, as you show
above.

Prehaps the set operation (message) should be "addUnique"
instead of "add". What you have above is sloppy and
inconsistent message overloading IMO.

(In most database systems, you set a unique column constraint
if you don't want the collection to have duplicate
columns. You can later remove the constraint without changing
the using code.)

Thanks for the example.
-T-



Thu, 15 Apr 2004 06:09:06 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

> > then why have ANY sub-divisions of collections

> The real answer to this and a lot of your other questions and
> arguments is that if we did things your way most software would be
> intolerably slow.  Since you aren't a real programmer you might have
> never encountered any situations where a program took thousands of
> times longer than it should have, but most people on these forums know
> what I mean.

So Amazon should run it's operations on Smalltalk collections
instead of Oracle because they don't have "real programmers"?

(BTW, I have used light and heavy DB engines. They come in all
sizes, or at least used to. Some operations or applications
were better under light engines and visa versa.)

-T-



Thu, 15 Apr 2004 06:09:08 GMT  
 Collection API's VI (was: OO-Process - Proof [T])
sigh.  Apparently, the word 'persistent' hasn't entered your vocabulary
either.  You need something to put data in <after> it comes out of the
database.  Regardless of the language used.
Quote:



>>>then why have ANY sub-divisions of collections

>>The real answer to this and a lot of your other questions and
>>arguments is that if we did things your way most software would be
>>intolerably slow.  Since you aren't a real programmer you might have
>>never encountered any situations where a program took thousands of
>>times longer than it should have, but most people on these forums know
>>what I mean.

> So Amazon should run it's operations on Smalltalk collections
> instead of Oracle because they don't have "real programmers"?

> (BTW, I have used light and heavy DB engines. They come in all
> sizes, or at least used to. Some operations or applications
> were better under light engines and visa versa.)

> -T-



Thu, 15 Apr 2004 07:05:26 GMT  
 Collection API's VI (was: OO-Process - Proof [T])
Topmind,

I think the very basic assumption in this discussion is wrong. Why different
types of collections should behave in the same way? Would you expect Integer
and Flow to work this way only because they are numbers?

Quote:

> > You seem to be missing the entire concept of polymorphism.  Just because
> > the methods (operations overlap) in their usage, does not mean they
> > overlap in their implementation.

> The API's are supposed to *hide* implimentation details. If
> you divide them by implementation, then you are overemphazing
> implementation. This is counter to OO philosophy, isn't it?

> > Nor their outcome.

> Different outcome == different interface

What you understand under the term "interface"?
Different outcome is not the same as different return type. Interfaces does
not define functional requirements. Interfaces are based on operation
signatures.

Quote:
> > Take for example
> > add: for List and for Set.  The set implementation must check for
> > duplicates but the list need not.  Also the outcome is different.

> > Set new add: 1; add: 1 add: 1       will end up with only one item.

> > List new add: 1; add: 1 add: 1    will end up with 3 items

> That means you cannot do both set and list operations on
> the same node or sets of nodes at the same time.
> This is counter to real world needs where one user
> may need one view and another a different view.

What is a node/set of nodes? I assume it is a collection.
You solve this kind of problems designing properly your data. You keep data in
a collection, from which you can derive all required views and present data to
different users by using different means. To use relational terminology you
basically use Set/List/whatever as a relational view/query. Different
languages/philosophies implicate different solutions/methodologies.

Quote:
> (This may not apply to adding elements, but
> it could apply to other operations.)

> Also, if one switches from a set to a list (or versa)
> because they need more functionality, then the using
> code is broke if it works differently, as you show
> above.

So will be any other code in any other application when you change
requirements.

Quote:
> (In most database systems, you set a unique column constraint
> if you don't want the collection to have duplicate
> columns. You can later remove the constraint without changing
> the using code.)

Kind of same with the collections. You do not have to change the code. You
will break it. So will you with your database example if the using code made
assumptions about uniqueness of values in the certain columns. No difference
here to me.

Regards, Jaroslaw.



Thu, 15 Apr 2004 07:11:50 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

<snip>

Quote:

>>Take for example
>>add: for List and for Set.  The set implementation must check for
>>duplicates but the list need not.  Also the outcome is different.

>>Set new add: 1; add: 1 add: 1       will end up with only one item.

>>List new add: 1; add: 1 add: 1    will end up with 3 items

> That means you cannot do both set and list operations on
> the same node or sets of nodes at the same time.
> This is counter to real world needs where one user
> may need one view and another a different view.
> (This may not apply to adding elements, but
> it could apply to other operations.)

of course you can't.  A Set object guarantees unique elements; a List
doesn't.  They are mutually exclusive.  Sometimes you want one,
sometimes the other.  You <never> want both at the same time unless you
   are utterly incompetent.

Quote:

> Also, if one switches from a set to a list (or versa)
> because they need more functionality, then the using
> code is broke if it works differently, as you show
> above.

mySet asList

myList asSet

Whoo boy, that was tough.  To repeat myself - if you had <ever> looked
at a Collection library, you would know this.  Instead, you continue to
make utterly absurd statements based on absolutely no information.

Quote:
> Prehaps the set operation (message) should be "addUnique"
> instead of "add". What you have above is sloppy and
> inconsistent message overloading IMO.

Sigh.  One could add such a method to class List if one needed it.  It
might be a bg clue that it's not there; i.e., in many, many years of
development by <lots> of smart people, no one has requested it as a
standard feature.

Quote:
> (In most database systems, you set a unique column constraint
> if you don't want the collection to have duplicate
> columns. You can later remove the constraint without changing
> the using code.)

So to paraphrase you idiocy, that is obviously broken - I may need
uniqueness and non-uniqueness at the same time.

- Show quoted text -

Quote:
> Thanks for the example.
> -T-



Thu, 15 Apr 2004 07:11:55 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

> sigh.  Apparently, the word 'persistent' hasn't entered your vocabulary
> either.  You need something to put data in <after> it comes out of the
> database.  Regardless of the language used.

Do you have something specific in mind?

Example time, boys and girls. Cliche time is over.

Quote:




> >>>then why have ANY sub-divisions of collections

> >>The real answer to this and a lot of your other questions and
> >>arguments is that if we did things your way most software would be
> >>intolerably slow.  Since you aren't a real programmer you might have
> >>never encountered any situations where a program took thousands of
> >>times longer than it should have, but most people on these forums know
> >>what I mean.

> > So Amazon should run it's operations on Smalltalk collections
> > instead of Oracle because they don't have "real programmers"?

> > (BTW, I have used light and heavy DB engines. They come in all
> > sizes, or at least used to. Some operations or applications
> > were better under light engines and visa versa.)

> > -T-



Thu, 15 Apr 2004 07:59:51 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:
> Topmind,

> I think the very basic assumption in this discussion is wrong. Why different
> types of collections should behave in the same way? Would you expect Integer
> and Flow to work this way only because they are numbers?

I assume you mean "float".

I am not sure what you mean. From a mathematical standpoint, they
do work the same way that I know of.

1 + 2 = 3

1.0 + 2.0 = 3.0

(Barring faulty math engines.)

I prefer type-free or auto-typing scripting languages anyhow.
They often don't make any visable distinction.

Quote:


> > > You seem to be missing the entire concept of polymorphism.  Just because
> > > the methods (operations overlap) in their usage, does not mean they
> > > overlap in their implementation.

> > The API's are supposed to *hide* implimentation details. If
> > you divide them by implementation, then you are overemphazing
> > implementation. This is counter to OO philosophy, isn't it?

> > > Nor their outcome.

> > Different outcome == different interface

> What you understand under the term "interface"?
> Different outcome is not the same as different return type.

In Smalltalk, interface defines "type", no?

Quote:
> Interfaces does
> not define functional requirements. Interfaces are based on operation
> signatures.

I am not sure I agree with this. I will have to ponder it.
Anybody else want to present their view on this?

There is more to "interface" than just names IMO.
"interface" is like a contract. The "add" contract
for Set is different from "add" for List.

- Show quoted text -

Quote:

> > > Take for example
> > > add: for List and for Set.  The set implementation must check for
> > > duplicates but the list need not.  Also the outcome is different.

> > > Set new add: 1; add: 1 add: 1       will end up with only one item.

> > > List new add: 1; add: 1 add: 1    will end up with 3 items

> > That means you cannot do both set and list operations on
> > the same node or sets of nodes at the same time.
> > This is counter to real world needs where one user
> > may need one view and another a different view.

> What is a node/set of nodes? I assume it is a collection.

More or less.

Quote:
> You solve this kind of problems designing properly your data. You keep data in
> a collection, from which you can derive all required views and present data to
> different users by using different means. To use relational terminology you
> basically use Set/List/whatever as a relational view/query. Different
> languages/philosophies implicate different solutions/methodologies.

Well, we certainly have different philosophies.

Quote:

> > (This may not apply to adding elements, but
> > it could apply to other operations.)

> > Also, if one switches from a set to a list (or versa)
> > because they need more functionality, then the using
> > code is broke if it works differently, as you show
> > above.

> So will be any other code in any other application when you change
> requirements.

I am not sure what you mean, especially in the light
of the fact that we seem to have some disagreement
over what "interface" means.

Quote:

> > (In most database systems, you set a unique column constraint
> > if you don't want the collection to have duplicate
> > columns. You can later remove the constraint without changing
> > the using code.)

> Kind of same with the collections. You do not have to change the code. You
> will break it.

"Add" would probably break the application in what was shown.

If "add" always means the same thing with a collection, you
reduce the chance of errors, you don't accidentally mix them up.

Quote:
> So will you with your database example if the using code made
> assumptions about uniqueness of values in the certain columns. No difference
> here to me.

Less so. There are vendor differences, but these are NOT due
to silly purposeful taxonomies. Most vendors support unique column
constraints. Besides, the constraints usually act as a sanity check
on behavior rather than define it. Code that never
violated a constraint under one vendor is not that
likely to violate it under another vendor.

Besides, you would have the same problem if you switched
your Set engine. You have 2 variants going on: "type"
and vendor, while a RDBMS only has one: vendor.

The taxonomy simply adds another dimension of
things to go wrong and get confused.

Quote:

> Regards, Jaroslaw.

-T-


Thu, 15 Apr 2004 07:59:54 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

> <snip>

> >>Take for example
> >>add: for List and for Set.  The set implementation must check for
> >>duplicates but the list need not.  Also the outcome is different.

> >>Set new add: 1; add: 1 add: 1       will end up with only one item.

> >>List new add: 1; add: 1 add: 1    will end up with 3 items

> > That means you cannot do both set and list operations on
> > the same node or sets of nodes at the same time.
> > This is counter to real world needs where one user
> > may need one view and another a different view.
> > (This may not apply to adding elements, but
> > it could apply to other operations.)

> of course you can't.  A Set object guarantees unique elements; a List
> doesn't.  They are mutually exclusive.  Sometimes you want one,
> sometimes the other.  You <never> want both at the same time unless you
> are utterly incompetent.

Sometimes somebody may not want to add
something if it is already there, while another person
or situation may not.

For example, take an error log. Suppose at first every
error was dumped into the error log. However, suppose
that some kinds of messages were way too common, or
unpreventable, such as "too many users on system",
clogging up the log during crucial times.

Thus, some messages you may want to only store one
regardless of how often it appeared,
while others you may want to store them all. Thus,
some messages you may want Set-like behavior, and
others you want List-like behavior.

Quote:

> > Also, if one switches from a set to a list (or versa)
> > because they need more functionality, then the using
> > code is broke if it works differently, as you show
> > above.

> mySet asList

> myList asSet

> Whoo boy, that was tough.  

Yeah, because you haven't used any "add" operations yet.
Definitions are only a small part of the whole pie.

Quote:
> To repeat myself - if you had <ever> looked
> at a Collection library, you would know this.  Instead, you continue to
> make utterly absurd statements based on absolutely no information.

And you are stuck in your narrow ways of looking at things.

IS-A is overused everywhere else in OOP, and collections
are no different. It was fun watching Meyer's head
smoke as he tried to divide Employees into subtypes.

Quote:

> > Prehaps the set operation (message) should be "addUnique"
> > instead of "add". What you have above is sloppy and
> > inconsistent message overloading IMO.

> Sigh.  One could add such a method to class List if one needed it.  It
> might be a bg clue that it's not there; i.e., in many, many years of
> development by <lots> of smart people, no one has requested it as a
> standard feature.

Because they get used to silly taxonomies and compensate.
If you chop somebody's hand off, they soon get used to it and adjust.
However, that does not mean that 2 hands are not more useful.

Quote:

> > (In most database systems, you set a unique column constraint
> > if you don't want the collection to have duplicate
> > columns. You can later remove the constraint without changing
> > the using code.)

> So to paraphrase you idiocy, that is obviously broken - I may need
> uniqueness and non-uniqueness at the same time.

See above.

Quote:

> > Thanks for the example.
> > -T-

-T-


Thu, 15 Apr 2004 07:59:58 GMT  
 Collection API's VI (was: OO-Process - Proof [T])


Wed, 18 Jun 1902 08:00:00 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

... snip ...

Quote:
> In Smalltalk, interface defines "type", no?

NO.

Interfaces, when provided as first class entities in smalltalk do formally
define a type. But types are not defined by interfaces. Type theory and its
discussion is a long and drawn out topic which in today's software
engineering world is full of poor or conflicting definitions and terminology
[especially problematic if you have weak theoretical foundation in type
theory for both functional/statically-typed languages and dynamically typed
languages]. Better to avoid that extremely overloaded word as it does us no
more good in colloquial discussion than using such terms as "category", etc.

An interface is a binding-scoped collection of behavi{*filter*}semantics that
describes a formalized contract between collaborators. Interfaces are units
of collaboration [aka contracts].

In other words it is a set of messages whose semantics have a specific
definition that all collaborating parties agree upon. The "interface"
definition enables client/providers/collaborators to provide or consume that
"interface/set-of" behavior without knowledge of the implementation or
representation of their fellow collaborators (peers, clients, or providers).
The degree to which the semantics are formally described or their
"correctness" is enforced statically or dynamically is a function of the
language facilities involved.

In classic Smalltalk, an interface is not a first class language entity. It
is only a conceptual entity typically defined in concrete form using
protocol/category tags on individual methods. As such, there is no notion of
re-use or mixin facilities for behavior or structure. There is also no
facility to distinguish or eliminate selector collisions. There is no
facility for obtaining an object/proxy that represents a given interface
(view) upon an object. There is no enforcement of any kind regarding the
contractual semantics. In classic smalltalk, it is common to find the
contractual semantics of interfaces being externally verified (and typically
expressed) through the use of unit-tests.

Some dialects, specifically QKS Smalltalk began providing first class
language entities for them in the early 90's [circa 1994]. My work on the
SmallScript language [a strict superset of classic smalltalk] has interfaces
as first class language entities that are fully integrated into the MOP. It
does allow selectors with the same name but defined within different
interfaces to be fully qualified/distinguished. It does provide the ability
to obtain an object that represents an interface (view) upon some object. It
does provide full support for the dynamic re-use and mixin facilities for
both behavior and structure at the class level and on down to a per/object
level. There is runtime enforcement available for contractual bindings of
message forms and the ability to provide hi-performance [and zero deployment
cost] pre/post condition verification also exists.

-- Dave S. [www.smallscript.org]

Quote:

> > Interfaces does
> > not define functional requirements. Interfaces are based on operation
> > signatures.

> I am not sure I agree with this. I will have to ponder it.
> Anybody else want to present their view on this?

> There is more to "interface" than just names IMO.
> "interface" is like a contract. The "add" contract
> for Set is different from "add" for List.

> > > > Take for example
> > > > add: for List and for Set.  The set implementation must check for
> > > > duplicates but the list need not.  Also the outcome is different.

> > > > Set new add: 1; add: 1 add: 1       will end up with only one item.

> > > > List new add: 1; add: 1 add: 1    will end up with 3 items

> > > That means you cannot do both set and list operations on
> > > the same node or sets of nodes at the same time.
> > > This is counter to real world needs where one user
> > > may need one view and another a different view.

> > What is a node/set of nodes? I assume it is a collection.

> More or less.

> > You solve this kind of problems designing properly your data. You keep
data in
> > a collection, from which you can derive all required views and present
data to
> > different users by using different means. To use relational terminology
you
> > basically use Set/List/whatever as a relational view/query. Different
> > languages/philosophies implicate different solutions/methodologies.

> Well, we certainly have different philosophies.

> > > (This may not apply to adding elements, but
> > > it could apply to other operations.)

> > > Also, if one switches from a set to a list (or versa)
> > > because they need more functionality, then the using
> > > code is broke if it works differently, as you show
> > > above.

> > So will be any other code in any other application when you change
> > requirements.

> I am not sure what you mean, especially in the light
> of the fact that we seem to have some disagreement
> over what "interface" means.

> > > (In most database systems, you set a unique column constraint
> > > if you don't want the collection to have duplicate
> > > columns. You can later remove the constraint without changing
> > > the using code.)

> > Kind of same with the collections. You do not have to change the code.
You
> > will break it.

... snip ...

> > Regards, Jaroslaw.

> -T-



Thu, 15 Apr 2004 08:54:07 GMT  
 Collection API's VI (was: OO-Process - Proof [T])


Wed, 18 Jun 1902 08:00:00 GMT  
 Collection API's VI (was: OO-Process - Proof [T])

Quote:

>Thus, some messages you may want to only store one
>regardless of how often it appeared,
>while others you may want to store them all. Thus,
>some messages you may want Set-like behavior, and
>others you want List-like behavior.

The most performant implementation of this is this:

Use some kind of structure to represent an ordered collection.  This could
be a liked list, or linked nodes, or similar structure.  This would provide
the best performance for a large error log.

Then we use some varient of a hash table, or if there is a huge variety of
error log entires, we would want to use a b-tree implementation, to lookup
the error log to test to see if the entries already exist.  If they already
exist, we don't need to waste time, we just continue on without adding
anything to the error log for these particular entries that are so common
that we want to avoid including them.

I don't care what programming language we use, be it Smalltalk, or machine
language, OODB or RDBMS, using the types of algorithms above are going to
yield the best performance for this kind of use.

Now in Smalltalk, we would commonly have an OrderedCollection, and a Set,
and the two would work together to provide the functionality we desire.

What could be easier then specifying that above directly as such?
What other algorithms do you think would be better performing for this
scenario?

So if this is the most ideal implementation, what is the problem with
specifying it simply as using an OrderedCollection and a Set, or defining a
common "add" behavior that does some tests..  Likely we might need to do
some other checks as well, such as perhaps certain errors at certain times
we might want to exclude altogether, so we create an "error log addition"
interface that takes care of all this behavior, and is responsible for
adding the errors where appropriate to the OrderedCollection and the Set.

And the problem is?

Ian



Thu, 15 Apr 2004 11:43:44 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. I am looking for a VI that login and logout users to a main VI.

2. convert's labview 6.1 vi's to labview 5.1 vi's

3. VI's GUI events disturb another VI's work

4. Why Ada can't be commercialized - devil's advocate proof

5. Timesaver error: Unknown Variable '%TS'

6. Top Ten Consultants' DON'Ts

7. Top Ten Consultants' DON'Ts

8. Ts 3.1 src in Ts 1.17

9. Which Collection am I in ?

10. e: Which Collection am I in ?

 

 
Powered by phpBB® Forum Software