| View previous topic :: View next topic |
| Author |
Message |
topmind
Guest
|
 Posted: Thu Oct 16, 2008 3:51 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
 |
|
On Oct 16, 12:30 am, "S Perryman" <a...@a.net> wrote:
| Quote: | "topmind" <topm...@technologist.com> wrote in message
news:b15de109-c169-4823-a84e-fcca02ef821e@25g2000prz.googlegroups.com...
On Oct 14, 8:25 pm, "Lee Riemenschneider" <newsu...@frogooa.com
wrote:
... and you claim there is no such concept among relations??? I think
we are only arguing semantics now.
I never said it was all-or-nothing. But OO philosophy tends to push
one toward pointer-handling/hopping *more often*. (I agree that most
RDBMS can improve in this area, though.)
Part of the reason is encapsulation. Encapsulation may guarantee that
the only way to "talk to" sub-components is to go through a pre-
defined set of accessors. This may be a lovely form of "protection" or
"control" by some standards, but the downside of this is that you MUST
go through those accessors even if they are not the best route. Thus,
the "access path" is hired wired by the developer.
For example, an OO developer may make "Paycheck" be a sub-component of
"Employee". The only way they allow to get to "Paycheck" is through
the Employee object/class. In relational if you don't need the
Employee entity you don't have to use (go through) the Employee
entity.
Rubbish.
Your scheme can only get to Paycheck if the system has provided an *extent
set* of Paycheck entities. And if the system has not ...
|
Please clarify or restate.
| Quote: |
The OO model makes no assumptions of, nor forces, the existence of an
extent set on a system.
|
Again, I said "tendency". It's not about "forces".
| Quote: |
Further, one often has to use archaic iterators (such as getNext) to
traverse through the paycheck objects because these are the only way
the developer allowed to perform collection-oriented actions on them.
Rubbish.
I can use the most basic collection capability in order to gather Paycheck
entities from a collection of associated Employee entities without the use
of an iterator ( "archaic" or otherwise) .
|
Depends on the language and the class arrangements.
| Quote: |
These one-at-a-time worm-crawls around hard-wired paths are the same
kind of thing that motivated Dr. Codd to seek a better solution in the
late 60's.
You still don't understand the difference between concept, and
implementation
of a concept.
|
Please provide useful information instead of insults.
| Quote: |
Set-oriented predicate processing and graph-traversal-oriented
processing have very different feels.
Rubbish.
As a graph is actually two sets, and a relationship between said sets,
there is no "different feel" whatsoever. By definition.
|
"Feel" controlled per formal definition?
Are you saying that say Prolog and Java have an identical "feel"?
| Quote: |
Regards,
Steven Perryman
|
-t- |
|
| |
|
 Back to top |
Lee Riemenschneider
Guest
|
| Posted: Fri Oct 17, 2008 1:25 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Wed, 15 Oct 2008 16:13:23 UTC, topmind <topmind@technologist.com>
wrote:
| Quote: | I never said it was all-or-nothing. But OO philosophy tends to push
one toward pointer-handling/hopping *more often*.
|
"tends to" ... be implemented as ...
We are traversing the same basic argument in that you have seen some
implementations done in an OOPL that have been unpalatable and
therefore conclude that all OT is suspect. It is a specious argument.
| Quote: | Part of the reason is encapsulation.
|
Encapsulation is an implementation concern.
--
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 |
Lee Riemenschneider
Guest
|
| Posted: Fri Oct 17, 2008 1:36 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Wed, 15 Oct 2008 06:54:19 UTC, "S Perryman" <a@a.net> wrote:
| Quote: | Fortunately for us, as far as the Relational model goes, those whose works
are important (Chris Date etc) , have no such fundamentally flawed
misunderstandings.
Date and Fabian Pascal have both made some generic sounding |
condemnations of OT. When I emailed them on it, they said their
comments should be read as only applying to OODBMS, but the language
used both at that time and in some papers afterwards failed to make
the distinction.
--
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 |
topmind
Guest
|
| Posted: Fri Oct 17, 2008 8:14 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
S Perryman wrote:
| Quote: |
What you call "pointer-hopping" is an *implementation* detail.
|
foo.bar.woozle.grobble.doSomething();
is not generally "implementation". It is a navigational *technique*.
It is an *abstraction* based on graph traversal paths.
You can keep calling it "implementation" 1000 times, but repetition
does not create truth.
| Quote: | Regards,
Steven Perryman
|
Unregards
-T- |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Fri Oct 17, 2008 8:19 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Oct 16, 6:25 pm, "Lee Riemenschneider" <newsu...@frogooa.com>
wrote:
| Quote: | On Wed, 15 Oct 2008 16:13:23 UTC, topmind <topm...@technologist.com
wrote:
I never said it was all-or-nothing. But OO philosophy tends to push
one toward pointer-handling/hopping *more often*.
"tends to" ... be implemented as ...
We are traversing the same basic argument in that you have seen some
implementations done in an OOPL that have been unpalatable and
therefore conclude that all OT is suspect. It is a specious argument.
|
Nobody agrees on what "good" OO is. That's not my fault. When OO is
"fixed" to avoid the downfalls or difficulties I see, the solution
tends to make it resemble relational.
| Quote: |
Part of the reason is encapsulation.
Encapsulation is an implementation concern.
|
Bullsh8t. It is an abstraction technique. (Whether a good or bad abs.
technique is another matter.)
| Quote: |
--
Lee W. Riemenschneider
GO BOILERS!
|
Go A/C's!
-T- |
|
| |
|
| Back to top |
S Perryman
Guest
|
| Posted: Fri Oct 17, 2008 8:21 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
"Lee Riemenschneider" <newsuser@frogooa.com> wrote in message
news:cIWOGgi2d1Id-pn2-KwfhS5we4hWX@ecs1...
| Quote: | On Wed, 15 Oct 2008 06:54:19 UTC, "S Perryman" <a@a.net> wrote:
Fortunately for us, as far as the Relational model goes, those whose
works
are important (Chris Date etc) , have no such fundamentally flawed
misunderstandings.
Date and Fabian Pascal have both made some generic sounding
condemnations of OT.
|
For those where are/were fans of 2nd generation Hip-Hip, I always think
of the line from Public Enemys' "Don't believe the hype" :
<quote>
Follower of Farrakhan,
Don't tell me that you understand, until you've heard the man.
</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.
As evidenced by the quote given.
And there are plenty more like that (his comments on the implications of the
Stonebraker "DBMS" matrix etc) .
| Quote: | When I emailed them on it, they said their
comments should be read as only applying to OODBMS, but the language
used both at that time and in some papers afterwards failed to make
the distinction.
|
Chris Date knows the way things are, and are going.
Although he does have flawed understanding of certain things relating to OO
(thinking that the Simula model of type substitutability is the only OO
model etc) ,
he at least knows that the 'data value' based realisations of the Relational
model
(SQL etc) are not enough for the systems development of now and the future.
Regards,
Steven Perryman |
|
| |
|
| Back to top |
S Perryman
Guest
|
| Posted: Fri Oct 17, 2008 8:21 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
"topmind" <topmind@technologist.com> wrote in message
news:77a48d8b-43e3-4c23-a708-3b35b2f496e3@i18g2000prf.googlegroups.com...
| Quote: | On Oct 16, 12:30 am, "S Perryman" <a...@a.net> wrote:
|
TM> I never said it was all-or-nothing. But OO philosophy tends to push
TM> one toward pointer-handling/hopping *more often*. (I agree that most
TM> RDBMS can improve in this area, though.)
TM> Part of the reason is encapsulation. Encapsulation may guarantee that
TM> the only way to "talk to" sub-components is to go through a pre-
TM> defined set of accessors. This may be a lovely form of "protection" or
TM> "control" by some standards, but the downside of this is that you MUST
TM> go through those accessors even if they are not the best route. Thus,
TM> the "access path" is hired wired by the developer.
TM> For example, an OO developer may make "Paycheck" be a sub-component of
TM> "Employee". The only way they allow to get to "Paycheck" is through
TM> the Employee object/class. In relational if you don't need the
TM> Employee entity you don't have to use (go through) the Employee
TM> entity.
| Quote: | Rubbish.
Your scheme can only get to Paycheck if the system has provided an
*extent
set* of Paycheck entities. And if the system has not ...
Please clarify or restate.
|
You do use SQL do you not ?? If so, you use extent sets.
So you understand what an extent set is.
| Quote: | The OO model makes no assumptions of, nor forces, the existence of an
extent set on a system.
Again, I said "tendency". It's not about "forces".
|
Doesn't change the outcome (the fallacy you have stated) .
| Quote: | I can use the most basic collection capability in order to gather
Paycheck
entities from a collection of associated Employee entities without the
use
of an iterator ( "archaic" or otherwise) .
Depends on the language and the class arrangements.
|
Feel free to show us how "language" and "class arrangements" (whatever that
actually means) , is the arbiter of whether I can construct the means to
apply
Relational expressions to collections of objects.
TM> These one-at-a-time worm-crawls around hard-wired paths are the same
TM> kind of thing that motivated Dr. Codd to seek a better solution in the
TM> late 60's.
| Quote: | You still don't understand the difference between concept, and
implementation of a concept.
Please provide useful information instead of insults.
|
What you call "pointer-hopping" is an *implementation* detail.
Just as Chris Date described in the text of his quoted in this thread.
When I manipulate collections of objects, I do so by using the constructs
of the Relational model. Information hiding means I make no assumptions
about
how relations, or relational expressions, are implemented under the covers.
TM> Set-oriented predicate processing and graph-traversal-oriented
TM> processing have very different feels.
| Quote: | Rubbish.
As a graph is actually two sets, and a relationship between said sets,
there is no "different feel" whatsoever. By definition.
"Feel" controlled per formal definition?
Are you saying that say Prolog and Java have an identical "feel"?
|
1a. Set : a collection of entities .
Multiple instances of an entity cannot be present in the collection.
1b. Graph : Set of Node, Set of Edge.
Relationship between Node and Edge (the "incidence" relation) .
2a. Prolog : Based on first-order predicate logic (Horn clauses in
particular) .
Parallel execution of program statements (clauses) is encouraged.
2b. Java : Object-oriented language.
Execution based on the block structured, imperative, sequential programming
paradigms.
Based on the above definitions :
Which as a whole do you consider to have an "identical feel" ?? 1 or 2 ...
Regards,
Steven Perryman |
|
| |
|
| Back to top |
S Perryman
Guest
|
| Posted: Fri Oct 17, 2008 2:56 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
"topmind" <topmind@technologist.com> wrote in message
news:8ca6d882-bc50-48c9-a3a7-8b542254c163@b2g2000prf.googlegroups.com...
| Quote: | S Perryman wrote:
What you call "pointer-hopping" is an *implementation* detail.
foo.bar.woozle.grobble.doSomething();
is not generally "implementation". It is a navigational *technique*.
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.
| Quote: | You can keep calling it "implementation" 1000 times, but repetition
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.
2. But unlike the OO form, forced to use extent sets.
Regards,
Steven Perryman |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Sat Oct 18, 2008 6:57 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
S Perryman wrote:
| Quote: | "topmind" <topmind@technologist.com> wrote in message
news:8ca6d882-bc50-48c9-a3a7-8b542254c163@b2g2000prf.googlegroups.com...
S Perryman wrote:
What you call "pointer-hopping" is an *implementation* detail.
foo.bar.woozle.grobble.doSomething();
is not generally "implementation". It is a navigational *technique*.
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.
|
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 says nothing of the human utility of the
concepts beyond the possibility of equivalency anymore than Turing
Equivalency tells us whether assembler language is "better than"
Python.
| Quote: |
You can keep calling it "implementation" 1000 times, but repetition
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.)
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. Pure encapsulation requires that each class has to explicitly be
given such behavior.
| 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.
| Quote: |
Regards,
Steven Perryman
|
-T- |
|
| |
|
| Back to top |
Phlip
Guest
|
| Posted: Sat Oct 18, 2008 5:36 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
Lee Riemenschneider wrote:
| Quote: | Encapsulation is an implementation concern.
|
OO is an implementation concern.
OO links it to encapsulation when the unit of polymorphism is also the unit
of encapsulation. The interface to a class provides decoupling at runtime
and at compile time.
--
Phlip |
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Sun Oct 19, 2008 4:22 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Oct 18, 5:36 am, "Phlip" <phlip2...@gmail.com> wrote:
| Quote: | Lee Riemenschneider wrote:
Encapsulation is an implementation concern.
OO is an implementation concern.
OO links it to encapsulation when the unit of polymorphism is also the unit
of encapsulation. The interface to a class provides decoupling at runtime
and at compile time.
--
Phlip
|
Without a clear-cut definition for "implementation", this conversation
will go on for a loooong time. Even a good working definition for the
scope of this discussion may due.
-t- |
|
| |
|
| Back to top |
Lee Riemenschneider
Guest
|
| Posted: Sun Oct 19, 2008 5:23 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Sat, 18 Oct 2008 12:36:37 UTC, "Phlip" <phlip2005@gmail.com> wrote:
| Quote: | Lee Riemenschneider wrote:
Encapsulation is an implementation concern.
OO is an implementation concern.
An interesting statement. If one were to say that some thing in the |
world can be abstracted as an object, is the object than an
abstraction or an implementation?
Maybe we should first define implementation. This entry from Wikipedia
looks like a decent definition, "In computer science, an
implementation is a realization of a technical specification or
algorithm as a program, software component, or other computer system.
Many implementations may exist for a given specification or standard."
We should probably also decide what OO means. I'm assuming object
oriented or object orientation and doesn't imply the use of an object
oriented programming language (OOPL).
Object orientation done via an object oriented programming language is
certainly an implementation, therefore use of an OOPL is an
implementation concern.
Object orientation can be done via a procedural language such as C, as
shown in Roger Sessions' book, Class Construction in C and C++. Is the
implementation concern in this case, the language chosen, OO, or both?
Object orientation can be done via a model. The model can be
elaborated to some programming language to run on a target computer
system, or can be translated into some programming language to run on
a target computer system. Is OO an implementation concern in this
case?
| Quote: | OO links it to encapsulation when the unit of polymorphism is also the unit
of encapsulation. The interface to a class provides decoupling at runtime
and at compile time.
I'm not quite sure what "it" refers to in the first sentence. I'm |
assuming implementation. I'm also not sure why polymorphism was
dragged into a discussion of encapsulation.
The second sentence seems to be referring to information hiding, which
leads us to deciding how to define encapsulation. Encapsulation is
often used with two different meanings:
1) Bundling data with methods that operate on the data.
2) Information hiding.
To say that encapsulation isn't an implementation concern, we have to
say that for either definition all possible implementations support
the concept. i.e., encapsulation is an abstract concept.
--
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 |
Phlip
Guest
|
| Posted: Sun Oct 19, 2008 5:42 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
| Quote: | I'm not quite sure what "it" refers to in the first sentence. I'm
assuming implementation. I'm also not sure why polymorphism was
dragged into a discussion of encapsulation.
|
Because, again, good OO lets you use the capsule of encapsulation as the
capsule of polymorphism. |
|
| |
|
| Back to top |
Lee Riemenschneider
Guest
|
| Posted: Sun Oct 19, 2008 8:22 pm Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
On Sun, 19 Oct 2008 12:42:24 UTC, "Phlip" <phlip2005@gmail.com> wrote:
| Quote: | Because, again, good OO lets you use the capsule of encapsulation as the
capsule of polymorphism.
"capsule of encapsualtion" is rather redundant. |
Of course, you ignored choosing any of my discriminations for use of
the terms OO and encapsulation, so it is still not clear what exactly
you are talking about.
I can't quite fathom what, good OO lets you use the encapsulation as
the encapsulation of polymorphism, means. Are you suggesting that,
good OO (all senses) defines the boundaries for polymorphism through
encapsulation (grouping sense), or are you stating the polymorphism
can't occur without information hiding?
--
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 |
Phlip
Guest
|
| Posted: Mon Oct 20, 2008 8:09 am Post subject: Re: OOP, this NG and you. Where is everyone? |
|
|
| Quote: | "capsule of encapsualtion" is rather redundant.
|
I needed a parallel construction for a parallel concept.
I don't know if we can get deeper into a "sky is blue" situation here. I am
not saying anything hard.
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. |
|
| |
|
| Back to top |
|
