| View previous topic :: View next topic |
| Author |
Message |
S Perryman
Guest
|
 Posted: Mon Oct 20, 2008 4:08 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
 |
|
"topmind" <topmind@technologist.com> wrote in message
news:573a7bc2-30da-4f69-9ede-30e41350669c@s9g2000prm.googlegroups.com...
TM> It is an *abstraction* based on graph traversal paths.
| Quote: | And a graph is a construct based on *sets* .
Therefore a graph is by definition a *set-theoretic* entity.
Yes, they are representationally interchangeable concepts, similar to
Turing Completeness, but for structures. But, this fact doesn't tell
us anything of use here.
|
It tells us plenty. Specifically that you don't understand what a graph is.
You have been given by me, definitions of a set and a graph (which BTW you
conveniently elided previously, to avoid replying to another claim you
made that was utter rubbish) .
Go back to those definitions, and feel free to show us how a set and
a graph are "representationally interchangeable" (whatever that actually
means) , "equivalent" , or anything else.
TM> You can keep calling it "implementation" 1000 times, but repetition
TM> does not create truth.
| Quote: | Collection<Grobble> g =
SELECT FROM
Grobble G, Woozle W, Bar B, Foo F
WHERE (F = foo) AND (B = F.Bar) AND
(W = B.Woozle) AND (G = W.Grobble) ;
FORALL e IN g : e.doSomething() ;
1.What is the above ?? A *navigation* technique.
QED.
I would note that some dialects of SQL support a "natural join" so
that one does not need to use key joins for the common relationships.
(I don't like how they support it, but it does exist as a real feature.)
|
The issue is not one of *syntax* , but of *semantics* .
For the example that you gave, the *relationship* has to be established
to bridge from Foo to Grobble. The syntax used to express that bridge
is irrelevant.
So once again, you have showed that by confusing semantics and
syntax, you do not understand the difference between concepts and
implementation of a concept.
| Quote: | All relational entities come with a built-in set of collection-
oriented operations/idioms ready to use out of the box. OOP does not
give you that, at least not without reinventing a database of some
kind.
|
Java provides a collection framework "ready to use out of the box" .
As does Smalltalk. As does C++ (the STL etc) . As does ...
So, no such "reinvention" of *any* kind is occurring.
| Quote: | Pure encapsulation requires that each class has to explicitly be
given such behavior.
|
Feel free to show us how encapsulation, which is a process of code
organisation, "requires" any type to be "explicitly" given "such behaviour"
(whatever "explicitly" or "behaviour" actually mean) .
| Quote: | 2. But unlike the OO form, forced to use extent sets.
Please explain. You keep using that term "extent sets", yet it has no
consistent Google identity.
|
This is basic maths.
If C is some concept, the extent set of C is the set of instances in a
universe
that conform to or satisfy C.
In SQL, a table T is, in the database (a universe) , the extent set of T.
Regards,
Steven Perryman |
|
| |
|
 Back to top |
topmind
Guest
|
| Posted: Mon Oct 20, 2008 5:58 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
S Perryman wrote:
| Quote: | "topmind" <topmind@technologist.com> wrote in message
news:573a7bc2-30da-4f69-9ede-30e41350669c@s9g2000prm.googlegroups.com...
S Perryman wrote:
TM> It is an *abstraction* based on graph traversal paths.
And a graph is a construct based on *sets* .
Therefore a graph is by definition a *set-theoretic* entity.
|
That is one of many possible definitions of "graph".
| Quote: |
Yes, they are representationally interchangeable concepts, similar to
Turing Completeness, but for structures. But, this fact doesn't tell
us anything of use here.
It tells us plenty. Specifically that you don't understand what a graph is.
|
Can't you ever have a conversation without sprinkling it with insults?
Its a bad habit that will leak into your paid work and you will get a
reputation for being an "arrogant grumpy techie", furthering the nasty
stereotype about us in general.
| Quote: |
You have been given by me, definitions of a set and a graph (which BTW you
conveniently elided previously, to avoid replying to another claim you
made that was utter rubbish) .
Go back to those definitions, and feel free to show us how a set and
a graph are "representationally interchangeable" (whatever that actually
means) , "equivalent" , or anything else.
|
I've used that term many times without complaint. It means that one
can represent the same semantic information in either "format". A
graph can be turned into a set(s) and visa versa to represent the same
info. The choice of what we actually use is more of human convenience
and/or machine performance issue rather than what each can or cannot
represent in an absolute sense.
| Quote: |
TM> You can keep calling it "implementation" 1000 times, but repetition
TM> does not create truth.
Collection<Grobble> g =
SELECT FROM
Grobble G, Woozle W, Bar B, Foo F
WHERE (F = foo) AND (B = F.Bar) AND
(W = B.Woozle) AND (G = W.Grobble) ;
FORALL e IN g : e.doSomething() ;
1.What is the above ?? A *navigation* technique.
QED.
I would note that some dialects of SQL support a "natural join" so
that one does not need to use key joins for the common relationships.
(I don't like how they support it, but it does exist as a real feature.)
The issue is not one of *syntax* , but of *semantics* .
For the example that you gave, the *relationship* has to be established
to bridge from Foo to Grobble. The syntax used to express that bridge
is irrelevant.
|
It's possible to save such info in advance so that we don't have to
keep stating it for each query. Sure, such is also possible with OOP.
But overall, it seems were comparing apples to oranges. You equate
each link in an object path to a table. This assumption can be and is
often false.
| Quote: |
So once again, you have showed that by confusing semantics and
syntax, you do not understand the difference between concepts and
implementation of a concept.
|
No. The problem is that "concepts" are "in the head". They are not
often not subject to objective conclusions, but instead are tied to
personal mental models. But, computers don't "care" about human
psychology or pet definitions. Usually we have to turn it into a
concrete implementation to form objective statements about something.
| Quote: |
All relational entities come with a built-in set of collection-
oriented operations/idioms ready to use out of the box. OOP does not
give you that, at least not without reinventing a database of some
kind.
Java provides a collection framework "ready to use out of the box" .
As does Smalltalk. As does C++ (the STL etc) . As does ...
So, no such "reinvention" of *any* kind is occurring.
|
If they were good enough as-is, then why use a database at all?
Partial answer:
1. One has to manually "attach" it to objects/classes. They don't
automatically get such behavior in many languages. (It's not an OOP
"requirement", but rather a bonus feature.)
2. Doesn't handle issues such as concurrency without screw addons.
3. Doesn't handle persistence without screwy addons. Forces a RAM-
versus-Disk mental dichotomy on the developer that generally doesn't
exist with DBMS.
4. Poor support for indexing, especially multi-indexing.
5. Poor support for usage outside of original language
| Quote: | 2. But unlike the OO form, forced to use extent sets.
Please explain. You keep using that term "extent sets", yet it has no
consistent Google identity.
This is basic maths.
If C is some concept, the extent set of C is the set of instances in a
universe
that conform to or satisfy C.
In SQL, a table T is, in the database (a universe) , the extent set of T.
|
Please reword it as something more concrete, such as a task that X can
do that Y cannot. You are implying an objective and clear flaw. Thus,
you should be able to give a scenario in which the flaw is exposed
without resorting to general academia-speak.
| Quote: |
Regards,
Steven Perryman
|
-T- |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Mon Oct 20, 2008 6:05 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Oct 17, 12:17 am, "S Perryman" <a...@a.net> wrote:
| Quote: | "Lee Riemenschneider" <newsu...@frogooa.com> wrote in message
news:cIWOGgi2d1Id-pn2-KwfhS5we4hWX@ecs1...
|
[...]
| Quote: |
Topmind all over.
Tries to use Date etc as an appeal to authority, but has even vaguely read
enough of his work to even understand his opinions.
|
When have I ever used Date as a reference for a critical point of a
debate? Or any "authority" for that matter? (Outside of definitions,
which are sometimes tied to authorities for good or bad.)
| Quote: |
Regards,
Steven Perryman
|
-T- |
|
| |
|
| Back to top |
Lee Riemenschneider
Guest
|
| Posted: Tue Oct 21, 2008 2:35 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Mon, 20 Oct 2008 03:09:00 UTC, "Phlip" <phlip2005@gmail.com> wrote:
| Quote: | "capsule of encapsualtion" is rather redundant.
I needed a parallel construction for a parallel concept.
Sorry, but that's nonsensical. |
| Quote: | I don't know if we can get deeper into a "sky is blue" situation here. I am
not saying anything hard.
No, but now (below) you've finally gotten around to stating it |
clearly.
| Quote: | If an OO language used one capsule for data hiding, and another for virtual
methods, it would be very difficult to use.
Hence, the OO languages we recognize use the concept of an interface. Both
data hiding and virtual methods occur at that same interface.
Now you've defined your terms. OO == OOPL; encapsulation means both |
grouping and information hiding.
You've still failed to show any correlation to polymorphism. There's
no reason stated to use "virtual methods" over just "methods". The
"virtual" implies polymorphism, but has no bearing on the case for
encapsulation.
However, this has gotten way off subject, and I think the problem is
the term implementation. I would suggest that a choice of an OOPL
implies an implementation, but maybe you are thinking that abstraction
in the OOPL stays above implementation.
--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com |
|
| |
|
| Back to top |
S Perryman
Guest
|
| Posted: Tue Oct 21, 2008 2:09 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
"topmind" <topmind@technologist.com> wrote in message
news:c9387bf3-086d-4f2d-9f68-2a79c86fdfbf@w39g2000prb.googlegroups.com...
SP> And a graph is a construct based on *sets* .
SP> Therefore a graph is by definition a *set-theoretic* entity.
| Quote: | That is one of many possible definitions of "graph".
|
Feel free to provide us with those that *you* are talking about.
TM> Yes, they are representationally interchangeable concepts, similar to
TM> Turing Completeness, but for structures. But, this fact doesn't tell
TM> us anything of use here.
| Quote: | It tells us plenty. Specifically that you don't understand what a graph
is.
Can't you ever have a conversation without sprinkling it with insults?
|
Sorry, but fact is not an insult.
Although we not you do like to claim the latter whenever faced with the
former.
You have consistently demonstrated that you do not understand the
difference between the concept of a set and a graph. Nor the very strong
relationship between the concepts.
As a result, you make claims that are in fact fallacy.
| Quote: | Its a bad habit that will leak into your paid work and you will get a
reputation for being an "arrogant grumpy techie", furthering the nasty
stereotype about us in general.
|
Believe me pal, by your actions on comp.object, you have have a reputation/
stereotype that pails your claim above into insignificance.
| Quote: | You have been given by me, definitions of a set and a graph (which BTW
you
conveniently elided previously, to avoid replying to another claim you
made that was utter rubbish) .
Go back to those definitions, and feel free to show us how a set and
a graph are "representationally interchangeable" (whatever that actually
means) , "equivalent" , or anything else.
I've used that term many times without complaint.
|
1. What "term" ??
2. You have yet to show us any of the things you claimed in the sentence
above.
| Quote: | It means that one can represent the same semantic information in either
"format".
|
What is a "format" ??
| Quote: | A graph can be turned into a set(s) and visa versa to represent the same
info.
|
Wrong.
Once again you have demonstrated that you do not understand the
difference between a set and a graph.
A graph is at its very minimum : a set + a *relation* .
At its worst : *two* sets + a relation.
TM> I would note that some dialects of SQL support a "natural join" so
TM> that one does not need to use key joins for the common relationships.
TM> (I don't like how they support it, but it does exist as a real feature.)
| Quote: | The issue is not one of *syntax* , but of *semantics* .
For the example that you gave, the *relationship* has to be established
to bridge from Foo to Grobble. The syntax used to express that bridge
is irrelevant.
It's possible to save such info in advance so that we don't have to
keep stating it for each query. Sure, such is also possible with OOP.
But overall, it seems were comparing apples to oranges.
|
What has any of this got to do with establishing the relationship (path)
between Foo and Grobble ??
| Quote: | You equate each link in an object path to a table. This assumption can be
and is
often false.
|
Rubbish.
What you term an "object path" is a relationship between *instances* .
A table is a representation of an extent set.
| Quote: | So once again, you have showed that by confusing semantics and
syntax, you do not understand the difference between concepts and
implementation of a concept.
No. The problem is that "concepts" are "in the head". They are not
often not subject to objective conclusions, but instead are tied to
personal mental models. But, computers don't "care" about human
psychology or pet definitions. Usually we have to turn it into a
concrete implementation to form objective statements about something.
|
Not for your fallacious claims we don't.
1. Everything that is applicable to a set (axioms etc) is applicable to a
graph.
Because a graph is a both a set-theoretic and relational concept.
So any claim about the failings of graphs is a claim against the concepts
that
underpin graphs.
2. You can argue about the *manner* in which a graph is *implemented* .
And that will (possibly) be fair comment.
But as we already know, the difference between 1 and 2 is ... (wait for it)
....
the difference between a concept and the *implementation* of the concept.
TM> All relational entities come with a built-in set of collection-
TM> oriented operations/idioms ready to use out of the box. OOP does not
TM> give you that, at least not without reinventing a database of some kind.
| Quote: | Java provides a collection framework "ready to use out of the box" .
As does Smalltalk. As does C++ (the STL etc) . As does ...
So, no such "reinvention" of *any* kind is occurring.
If they were good enough as-is, then why use a database at all?
Partial answer:
|
See below ...
Real answer : because you use something that is *already available*
and *good enough* to do the jobs you need to do. And when that
something isn't : you use something else.
| Quote: | 1. One has to manually "attach" it to objects/classes. They don't
automatically get such behavior in many languages. (It's not an OOP
"requirement", but rather a bonus feature.)
|
Please feel free to show us examples of doing "manual attach" to objects/
classes.
| Quote: | 2. Doesn't handle issues such as concurrency without screw addons.
|
Concurrency is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
| Quote: | 3. Doesn't handle persistence without screwy addons. Forces a RAM-
versus-Disk mental dichotomy on the developer that generally doesn't
exist with DBMS.
|
Persistence is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
| Quote: | 4. Poor support for indexing, especially multi-indexing.
|
1. Indexing is an implementation technique.
2. Feel free to show us how indexing, especially "multi-indexing"
has "poor support" in OOP.
| Quote: | 5. Poor support for usage outside of original language
|
1. This sentence is utterly meaningless.
2. In the event that I have discerned a meaning, you mean like
not as good as Embedded SQL etc ??
| Quote: | This is basic maths.
If C is some concept, the extent set of C is the set of instances in a
universe that conform to or satisfy C.
In SQL, a table T is, in the database (a universe) , the extent set of T.
Please reword it as something more concrete, such as a task that X can
do that Y cannot. You are implying an objective and clear flaw.
|
Please feel free to show us how a mathematical definition, as given above,
implies a "flaw" ( "objective" , "clear" or other) of any kind.
Again, you show your inability to understand the difference between a
concept and implementation of a concept (in this case your navigation
example, where the OO form implies no particular implementation, and
an SQL-esque form which uses extent sets) .
Regards,
Steven Perryman |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Tue Oct 21, 2008 3:44 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Oct 21, 2:09 am, "S Perryman" <a...@a.net> wrote:
| Quote: | "topmind" <topm...@technologist.com> wrote in message
news:c9387bf3-086d-4f2d-9f68-2a79c86fdfbf@w39g2000prb.googlegroups.com...
S Perryman wrote:
SP> And a graph is a construct based on *sets* .
SP> Therefore a graph is by definition a *set-theoretic* entity.
That is one of many possible definitions of "graph".
Feel free to provide us with those that *you* are talking about.
|
m-w.com:
"a collection of vertices and edges that join pairs of vertices"
Aka, "circles and arrows".
| Quote: |
TM> Yes, they are representationally interchangeable concepts, similar to
TM> Turing Completeness, but for structures. But, this fact doesn't tell
TM> us anything of use here.
It tells us plenty. Specifically that you don't understand what a graph
is.
Can't you ever have a conversation without sprinkling it with insults?
Sorry, but fact is not an insult.
Although we not you do like to claim the latter whenever faced with the
former.
You have consistently demonstrated that you do not understand the
difference between the concept of a set and a graph. Nor the very strong
relationship between the concepts.
|
You always insult me such that I generally ignore it. You've called
wolf too many times. And your media-library "combinatorial explosion"
weasily face-fall drained you of any credibility.
| Quote: |
As a result, you make claims that are in fact fallacy.
Its a bad habit that will leak into your paid work and you will get a
reputation for being an "arrogant grumpy techie", furthering the nasty
stereotype about us in general.
Believe me pal, by your actions on comp.object, you have have a reputation/
stereotype that pails your claim above into insignificance.
|
Even if I was bad and stupid as you claim, two wrongs don't make a
right.
| Quote: |
You have been given by me, definitions of a set and a graph (which BTW
you
conveniently elided previously, to avoid replying to another claim you
made that was utter rubbish) .
Go back to those definitions, and feel free to show us how a set and
a graph are "representationally interchangeable" (whatever that actually
means) , "equivalent" , or anything else.
I've used that term many times without complaint.
1. What "term" ??
|
"representationally equivalent"
| Quote: |
2. You have yet to show us any of the things you claimed in the sentence
above.
It means that one can represent the same semantic information in either
"format".
What is a "format" ??
|
"Sets" versus "graphs". "Structure" may be a better description.
| Quote: |
A graph can be turned into a set(s) and visa versa to represent the same
info.
Wrong.
Once again you have demonstrated that you do not understand the
difference between a set and a graph.
|
I've never found a graph that I couldn't convert into sets and vise
versa. I won't claim here that *all* are interchangeable because there
may be some weird boundary conditions under some weird math models,
but a "typical" one is convertible.
| Quote: |
A graph is at its very minimum : a set + a *relation* .
At its worst : *two* sets + a relation.
|
Worst?
| Quote: |
TM> I would note that some dialects of SQL support a "natural join" so
TM> that one does not need to use key joins for the common relationships.
TM> (I don't like how they support it, but it does exist as a real feature.)
The issue is not one of *syntax* , but of *semantics* .
For the example that you gave, the *relationship* has to be established
to bridge from Foo to Grobble. The syntax used to express that bridge
is irrelevant.
It's possible to save such info in advance so that we don't have to
keep stating it for each query. Sure, such is also possible with OOP.
But overall, it seems were comparing apples to oranges.
What has any of this got to do with establishing the relationship (path)
between Foo and Grobble ??
|
It may *not* matter in that particular case. I'm just saying it can be
done.
[...]
| Quote: |
Not for your fallacious claims we don't.
1. Everything that is applicable to a set (axioms etc) is applicable to a
graph.
Because a graph is a both a set-theoretic and relational concept.
|
Plural: sets, not set.
| Quote: | TM> All relational entities come with a built-in set of collection-
TM> oriented operations/idioms ready to use out of the box. OOP does not
TM> give you that, at least not without reinventing a database of some kind.
Java provides a collection framework "ready to use out of the box" .
As does Smalltalk. As does C++ (the STL etc) . As does ...
So, no such "reinvention" of *any* kind is occurring.
If they were good enough as-is, then why use a database at all?
Partial answer:
See below ...
Real answer : because you use something that is *already available*
and *good enough* to do the jobs you need to do. And when that
something isn't : you use something else.
|
So If you need the features listed later, you dump most your OOP code
and start over? That doesn't sound economic.
| Quote: |
1. One has to manually "attach" it to objects/classes. They don't
automatically get such behavior in many languages. (It's not an OOP
"requirement", but rather a bonus feature.)
Please feel free to show us examples of doing "manual attach" to objects/
classes.
|
Can you list common OOPL languages with automatic attachment?
| Quote: |
2. Doesn't handle issues such as concurrency without screw addons.
Concurrency is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
|
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such with an add-on.
| Quote: |
3. Doesn't handle persistence without screwy addons. Forces a RAM-
versus-Disk mental dichotomy on the developer that generally doesn't
exist with DBMS.
Persistence is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
|
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such an add-on.
| Quote: |
4. Poor support for indexing, especially multi-indexing.
1. Indexing is an implementation technique.
|
So? If the feature is missing, it is missing. In *practice* OOPL's
don't pay much attention to rich collection orientation.
| Quote: |
2. Feel free to show us how indexing, especially "multi-indexing"
has "poor support" in OOP.
|
If you use a collection class that does not support multi-indexing,
then it does not support it. You may not even be able to alter the
internals to change the implementation to support it.
| Quote: |
5. Poor support for usage outside of original language
1. This sentence is utterly meaningless.
|
Only to those who stick their OO head in the OO sand. What if I want
to get info from Java collections from a Python app?
| Quote: |
2. In the event that I have discerned a meaning, you mean like
not as good as Embedded SQL etc ??
|
Embedded?
| Quote: |
Regards,
Steven Perryman
|
-T- |
|
| |
|
| Back to top |
Phlip
Guest
|
| Posted: Wed Oct 22, 2008 9:21 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
| Quote: | I needed a parallel construction for a parallel concept.
Sorry, but that's nonsensical.
|
It cites /The Elements of Style/. You use parallel construction on parallel
concepts. For example, that statement uses parallel twice - both times as a
preposition with an object.
Violating the ideal gives: "Use the same pattern of construction for
concepts that are parallel." Very damaging!
So, in OO, the same interface provides both virtual dispatch and
data-hiding. |
|
| |
|
| Back to top |
S Perryman
Guest
|
| Posted: Wed Oct 22, 2008 3:05 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
"topmind" <topmind@technologist.com> wrote in message
news:a0c5e4e4-69c2-4e02-8105-08b59bf1fedb@z6g2000pre.googlegroups.com...
| Quote: | On Oct 21, 2:09 am, "S Perryman" <a...@a.net> wrote:
|
SP> And a graph is a construct based on *sets* .
SP> Therefore a graph is by definition a *set-theoretic* entity.
TM> That is one of many possible definitions of "graph".
| Quote: | Feel free to provide us with those that *you* are talking about.
m-w.com:
"a collection of vertices and edges that join pairs of vertices"
|
That is close to the second part of the canonical definition that I gave.
Good. You have cited a source that is in close agreement with me.
| Quote: | Aka, "circles and arrows".
|
Aka = "also known as" , does it not.
Feel free to show us where in the mainstream that mathematical graphs are
also referred to as "circles and arrows" . And more interestingly, which
*form*
of graph (directed, undirected) they refer to.
| Quote: | Sorry, but fact is not an insult.
Although we not you do like to claim the latter whenever faced with the
former.
You have consistently demonstrated that you do not understand the
difference between the concept of a set and a graph. Nor the very strong
relationship between the concepts.
You always insult me such that I generally ignore it.
|
You would have been better to ignore it.
But because it is fact, not insult, perhaps that is why you were compelled
to
respond.
| Quote: | You've called wolf too many times.
|
Irrelevant to the topic being discussed.
| Quote: | And your media-library "combinatorial explosion"
weasily face-fall drained you of any credibility.
|
1. Irrelevant to the topic being discussed.
2. Your usual pathetic attempt to deflect the discussion away from your
fallacies.
BTW, how did you get on with the 100s of object types, with the 100s of
properties which may be unique to certain types or shared between types ??
How did the 100+ X 100+ different property permutations (ie a combinatorial
explosion) work in your "solution" with millions of object instances (ie the
real
world problem that I and others have solved with OO) ??
I never do get an answer to this one, do I (wonder why) ...
| Quote: | Believe me pal, by your actions on comp.object, you have have a
reputation/
stereotype that pails your claim above into insignificance.
Even if I was bad and stupid as you claim, two wrongs don't make a right.
|
Physician, heal thyself.
SP> Go back to those definitions, and feel free to show us how a set and
SP> a graph are "representationally interchangeable" (whatever that actually
SP> means) , "equivalent" , or anything else.
| Quote: | I've used that term many times without complaint.
1. What "term" ??
"representationally equivalent"
|
1. Where have you used this term "many times" ??
2. What does it *actually mean* ??
| Quote: | 2. You have yet to show us any of the things you claimed in the sentence
above.
It means that one can represent the same semantic information in either
"format".
What is a "format" ??
"Sets" versus "graphs". "Structure" may be a better description.
|
Nope. Still meaningless goobledygook.
TM> A graph can be turned into a set(s) and visa versa to represent the same
TM> info.
| Quote: | Wrong.
Once again you have demonstrated that you do not understand the
difference between a set and a graph.
I've never found a graph that I couldn't convert into sets and vise versa.
|
So what you are saying is that you have never found an entity, that is
defined in set-theoretic terms, that cannot be converted into sets (the
fundamental set-theoretic concept) ??
What does that tell you about the relationship between sets and graphs ...
??
| Quote: | A graph is at its very minimum : a set + a *relation* .
At its worst : *two* sets + a relation.
Worst?
|
If edges have properties associated with them, then a set of edges must be
defined. If edges have no properties, only a set of nodes + the incidence
relation
are needed. By definition.
| Quote: | 1. Everything that is applicable to a set (axioms etc) is applicable to a
graph. Because a graph is a both a set-theoretic and relational concept.
Plural: sets, not set.
|
Meaningless sentence.
TM> All relational entities come with a built-in set of collection-
TM> oriented operations/idioms ready to use out of the box. OOP does not
TM> give you that, at least not without reinventing a database of some kind.
SP>Java provides a collection framework "ready to use out of the box" .
SP> As does Smalltalk. As does C++ (the STL etc) . As does ...
SP> So, no such "reinvention" of *any* kind is occurring.
SP> If they were good enough as-is, then why use a database at all?
TM> Partial answer:
| Quote: | See below ...
Real answer : because you use something that is *already available*
and *good enough* to do the jobs you need to do. And when that
something isn't : you use something else.
So If you need the features listed later, you dump most your OOP code
and start over? That doesn't sound economic.
|
It would be so, if you attempt to use something to solve problems that it is
not
fit for purpose to do, and persist in using that something regardless
because
it is being used to adequately solve *some* (not all) current problems.
TM> 1. One has to manually "attach" it to objects/classes. They don't
TM> automatically get such behavior in many languages. (It's not an OOP
TM> "requirement", but rather a bonus feature.)
| Quote: | Please feel free to show us examples of doing "manual attach" to
objects/classes.
Can you list common OOPL languages with automatic attachment?
|
When I understand what "automatic" and "manual" "attachment" is, perhaps I
can.
As they appear to be terms of your own making, please feel free to give us
definitions/examples of "automatic" and "manual" "attachment" .
You have now been asked twice for the latter, have you not.
TM> 2. Doesn't handle issues such as concurrency without screw addons.
| Quote: | Concurrency is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such with an add-on.
|
In C++ , feel free to look at stuff like C++ implementations of pthreads
(the Posix thread library) . Or the ACE libraries. Or (you get the idea) ...
Similarly for other OO prog langs.
TM> 3. Doesn't handle persistence without screwy addons. Forces a RAM-
TM> versus-Disk mental dichotomy on the developer that generally doesn't
TM> exist with DBMS.
| Quote: | Persistence is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such an add-on.
|
type Persistent<T> conforms-to T
{
store(...) ;
retrieve(...) ;
} ;
type Sequence { ... } ;
Persistent<Sequence> store(...)
{
// the implementation details
}
Sequence s ;
Persistent<Sequence> p(s) ;
p.store(...) ;
Orthogonal (provided independently of the types for which persistence
may be required) .
Similar approaches can be used for concurrency too.
TM> 4. Poor support for indexing, especially multi-indexing.
| Quote: | 1. Indexing is an implementation technique.
So? If the feature is missing, it is missing. In *practice* OOPL's
don't pay much attention to rich collection orientation.
|
What does "rich collection orientation" mean ??
| Quote: | 2. Feel free to show us how indexing, especially "multi-indexing"
has "poor support" in OOP.
If you use a collection class that does not support multi-indexing,
then it does not support it.
|
Prevarication prevarication. Evasion evasion.
If you claim that OOP has "poor support" for this aspect, the burden
of proof is on you to provide the info that demonstrates your case.
| Quote: | You may not even be able to alter the
internals to change the implementation to support it.
|
Currently meaningless.
That may change of course when we get answers to your claims.
TM> 5. Poor support for usage outside of original language
| Quote: | 1. This sentence is utterly meaningless.
Only to those who stick their OO head in the OO sand. What if I want
to get info from Java collections from a Python app?
|
XML ?? Network comms protocols ??
Any other *std info interchange schemes* defined out there in the world ??
| Quote: | 2. In the event that I have discerned a meaning, you mean like
not as good as Embedded SQL etc ??
Embedded?
|
You don't know what "Embedded" SQL is ?? Yes or no will suffice.
Regards,
Steven Perryman |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Wed Oct 22, 2008 3:32 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
S Perryman wrote:
| Quote: | "topmind" <topmind@technologist.com> wrote in message
news:a0c5e4e4-69c2-4e02-8105-08b59bf1fedb@z6g2000pre.googlegroups.com...
On Oct 21, 2:09 am, "S Perryman" <a...@a.net> wrote:
SP> And a graph is a construct based on *sets* .
SP> Therefore a graph is by definition a *set-theoretic* entity.
TM> That is one of many possible definitions of "graph".
Feel free to provide us with those that *you* are talking about.
m-w.com:
"a collection of vertices and edges that join pairs of vertices"
That is close to the second part of the canonical definition that I gave.
Good. You have cited a source that is in close agreement with me.
Aka, "circles and arrows".
Aka = "also known as" , does it not.
Feel free to show us where in the mainstream that mathematical graphs are
also referred to as "circles and arrows" . And more interestingly, which
*form*
of graph (directed, undirected) they refer to.
|
I've shown that your def is not universally accepted. I have no need
to answer your second baiting question.
| Quote: | You've called wolf too many times.
Irrelevant to the topic being discussed.
|
You started the insults, not me. Now you are saying the insults are
"irrelevant"? Trying to have it both ways?
| Quote: |
And your media-library "combinatorial explosion"
weasily face-fall drained you of any credibility.
1. Irrelevant to the topic being discussed.
2. Your usual pathetic attempt to deflect the discussion away from your
fallacies.
BTW, how did you get on with the 100s of object types, with the 100s of
properties which may be unique to certain types or shared between types ??
|
What are you talking about? There was no such thing in the media
library problem space.
| Quote: |
How did the 100+ X 100+ different property permutations (ie a combinatorial
explosion) work in your "solution" with millions of object instances (ie the
real
world problem that I and others have solved with OO) ??
I never do get an answer to this one, do I (wonder why) ...
|
Because you never showed it in a realistic scenario. One does not
have to use "types" if its the WRONG TOOL. Its like, "How are you
going to prevent denting the floor when you swing that sledge hammer
100 times to kill those 100 roaches?" Just because you force "types"
out of stubborn personal dogma does not mean everyone else has to.
| Quote: | SP> Go back to those definitions, and feel free to show us how a set and
SP> a graph are "representationally interchangeable" (whatever that actually
SP> means) , "equivalent" , or anything else.
I've used that term many times without complaint.
1. What "term" ??
"representationally equivalent"
1. Where have you used this term "many times" ??
|
I don't keep track of every debate or posting with it.
| Quote: | 2. What does it *actually mean* ??
|
That the same info can be represented with set(s) or graph(s). Why are
you getting hung up on this?
| Quote: | TM> A graph can be turned into a set(s) and visa versa to represent the same
TM> info.
Wrong.
Once again you have demonstrated that you do not understand the
difference between a set and a graph.
I've never found a graph that I couldn't convert into sets and vise versa.
So what you are saying is that you have never found an entity, that is
defined in set-theoretic terms, that cannot be converted into sets (the
fundamental set-theoretic concept) ??
What does that tell you about the relationship between sets and graphs ...
??
|
They are "representationally equivalent".
| Quote: | TM> All relational entities come with a built-in set of collection-
TM> oriented operations/idioms ready to use out of the box. OOP does not
TM> give you that, at least not without reinventing a database of some kind.
SP>Java provides a collection framework "ready to use out of the box" .
SP> As does Smalltalk. As does C++ (the STL etc) . As does ...
SP> So, no such "reinvention" of *any* kind is occurring.
SP> If they were good enough as-is, then why use a database at all?
TM> Partial answer:
See below ...
Real answer : because you use something that is *already available*
and *good enough* to do the jobs you need to do. And when that
something isn't : you use something else.
So If you need the features listed later, you dump most your OOP code
and start over? That doesn't sound economic.
It would be so, if you attempt to use something to solve problems that it is
not
fit for purpose to do, and persist in using that something regardless
because
it is being used to adequately solve *some* (not all) current problems.
|
So OOP is not scalable, eh?
| Quote: | TM> 2. Doesn't handle issues such as concurrency without screw addons.
Concurrency is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such with an add-on.
In C++ , feel free to look at stuff like C++ implementations of pthreads
(the Posix thread library) . Or the ACE libraries. Or (you get the idea) ...
Similarly for other OO prog langs.
|
Code example?
| Quote: |
TM> 3. Doesn't handle persistence without screwy addons. Forces a RAM-
TM> versus-Disk mental dichotomy on the developer that generally doesn't
TM> exist with DBMS.
Persistence is an orthogonal concept.
Orthogonal concepts are *easy* "add-ons" .
If your class doesn't support it, then it doesn't support it. Please
feel free to show us examples of doing such an add-on.
type Persistent<T> conforms-to T
{
store(...) ;
retrieve(...) ;
} ;
type Sequence { ... } ;
Persistent<Sequence> store(...)
{
// the implementation details
}
Sequence s ;
Persistent<Sequence> p(s) ;
p.store(...) ;
Orthogonal (provided independently of the types for which persistence
may be required) .
Similar approaches can be used for concurrency too.
|
Swapping interfaces does not by itself CREATE new functionality. I
can define any interface I want:
myProject.doAllMyWorkForMeAndReadTheBossesMind();
but that does not mean the functionality exists. More on this below in
the DLL scenario.
| Quote: |
TM> 4. Poor support for indexing, especially multi-indexing.
1. Indexing is an implementation technique.
So? If the feature is missing, it is missing. In *practice* OOPL's
don't pay much attention to rich collection orientation.
What does "rich collection orientation" mean ??
|
I already gave examples: concurrency, RAM/disk transparency, multi-
indexing, set operations, predicates, etc.
| Quote: |
2. Feel free to show us how indexing, especially "multi-indexing"
has "poor support" in OOP.
If you use a collection class that does not support multi-indexing,
then it does not support it.
Prevarication prevarication. Evasion evasion.
If you claim that OOP has "poor support" for this aspect, the burden
of proof is on you to provide the info that demonstrates your case.
|
I cannot prove that Santa does not exist. It's your job to prove that
he does exist if you claim it.
| Quote: |
You may not even be able to alter the
internals to change the implementation to support it.
Currently meaningless.
That may change of course when we get answers to your claims.
|
If the implementation of the collection engine is say a compiled DLL,
one may not be able to add indexing to it. You can add to and override
the interface all you want, but you cannot add multi-indexing that
works with the existing collection engine. Unless the collection
engine exposes lots of internal guts info, the only way to get it is
to create a new collection engine from scratch or hack the machine
language of the DLL.
| Quote: |
TM> 5. Poor support for usage outside of original language
1. This sentence is utterly meaningless.
Only to those who stick their OO head in the OO sand. What if I want
to get info from Java collections from a Python app?
XML ?? Network comms protocols ??
Any other *std info interchange schemes* defined out there in the world ??
|
Ah, so you reinvent the database, using XML as your query language. I
see.
| Quote: |
2. In the event that I have discerned a meaning, you mean like
not as good as Embedded SQL etc ??
Embedded?
You don't know what "Embedded" SQL is ?? Yes or no will suffice.
|
Embedded is an ambiguous term. It can mean included with the language
(compiled "in"), or that the app code has SQL inside of the source.
| Quote: |
Regards,
Steven Perryman
|
-T- |
|
| |
|
| Back to top |
Lee Riemenschneider
Guest
|
| Posted: Thu Oct 23, 2008 12:58 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Wed, 22 Oct 2008 04:21:25 UTC, "Phlip" <phlip2005@gmail.com> wrote:
| Quote: | I needed a parallel construction for a parallel concept.
Sorry, but that's nonsensical.
It cites /The Elements of Style/. You use parallel construction on parallel
concepts.
|
Sorry, I wasn't referring to sentence; I was referring to polymorphism
and encapsulation being parallel concepts. I have in front of me a
chapter by Gordon Brown in the book Object Development Methods titled,
The Four Dimensions of Object-Oriented Methods, in which he states,
"This chapter presents a view of object-oriented concepts based on
four orthogonal dimensions: encapsulation, classification,
polymorphism, and interpretation." I would not say this is the only
source that would present polymorphism and encapsulation as orthogonal
concepts.
--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com |
|
| |
|
| Back to top |
Daniel Parker
Guest
|
| Posted: Thu Oct 23, 2008 4:25 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Oct 23, 7:26 am, "Phlip" <phlip2...@gmail.com> wrote:
| Quote: |
I have in front of me a
chapter by Gordon Brown in the book Object Development Methods titled,
The Four Dimensions of Object-Oriented Methods, in which he states,
"This chapter presents a view of object-oriented concepts based on
four orthogonal dimensions:
|
The Four Dimensions of Object-Oriented Methods, published in 1994, I
guess this is a good example of the kind of book (almost) nobody reads
anymore, and the kind of book it wouldn't be possible to publish
anymore. It's been displaced by books with titles like "SOA: Value
dimensions of SOA explained". Hint: there is no benefit to reading
any of these books.
| Quote: | I am very tired of this conversation. Parallel construction in sentences
improves the orthogonality of the topic.
|
You mean it makes the orthoganality better, in some sense?
| Quote: | Claiming I meant something else by it is a rhetorical game.
|
I would hesitate to claim you meant anything by it, let alone
"something else".
It's interesting that threads like this on the subject of whether OO
is good for anything have always been the ones that have turned into
the long threads. The number of topics does seem to be limited.
But at least we have out programming languages, supporting "A
implements I" or "A :I", because that's mostly all that's left.
-- Daniel |
|
| |
|
| Back to top |
Phlip
Guest
|
| Posted: Thu Oct 23, 2008 4:26 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
| Quote: | It cites /The Elements of Style/. You use parallel construction on
parallel
concepts.
Sorry, I wasn't referring to sentence; I was referring to polymorphism
and encapsulation being parallel concepts. I have in front of me a
chapter by Gordon Brown in the book Object Development Methods titled,
The Four Dimensions of Object-Oriented Methods, in which he states,
"This chapter presents a view of object-oriented concepts based on
four orthogonal dimensions: encapsulation, classification,
polymorphism, and interpretation." I would not say this is the only
source that would present polymorphism and encapsulation as orthogonal
concepts.
|
I am very tired of this conversation. Parallel construction in sentences
improves the orthogonality of the topic. Claiming I meant something else by
it is a rhetorical game. |
|
| |
|
