Searching OO Associations with RDBMS Persistence Models
Richie
What is the best way to implement the following search
Give me all companies that start with "Micro" in Seattle, Washington
Class Diagram Below (The DB Diagram is also the same, where Location
has a companyID referencing a Company)
+---------+
| Company |
+---------+
|1
|
|1..*
+----------+
| Location |
+----------+
"Company is located at location X. Company has at least one location."
"Location belongs to Company X"
The company class implements the association through
Class Company
{
String companyName;
Set locations;
public void addLocation(location)
{};
}
******The part that gets me is this.
The typical search in this scenario is
Give me all companies that start with "Micro" in Seattle, Washington
This means that the search is across two classes - Company AND Location
************************
In the database world, this is a simple join across two tables.
*************************
I've spent several hours on the lists, and have read a number of posts
that reference the same issue, but came across none that answered it
practical terms.
So I'd like to preface the question by saying that if the only
persistence model available to use was an RDBMS and OO was the only
design methodology. Given that, what is the best methodology for
solving the problem.
What is the correct correlation of this in a Object Oriented World.
1) Do I create another class called CompanyLocations that does the
search and creates the objects as needed. This doesn't work too well in
my opinion as the relationship does extend further to Locations have
Employees...would this mean that I would need a CompanyLocationEmployee
Class for searches?
2) Do I create a method search() in COmpany that returns all Companies
that start with "Micro" and then loop through these to search for
locations that match Seattle, WA?
3) Do I fudge the Object Orientation, in Company and create a
search(companyName, city, state) method that searches across the
tables? And creates the necessary location instances as well?
4) Am I making a mountain out of a mole hill?
Thanks in advance
Richie
fre...@gmail.com
as the lack of replies indicates, there are no good solution for your
problem. OOA/D does not provide any tools for non-trivial searches like
your. Using OOA/D, the standard solution would be to create a
findByNameStartingWithAndByLocation()-method in the Company class. The
implementation of the find-method would use SQL.
Many OO evangelists claim that searches are not needed in well design
OO applications. You have to redesign your application to avoid the
scenario above. Obviously reporting, etc, should not be done using
OOA/D.
Fredrik Bertilsson
http://moonbird.sourceforge.net
H. S. Lahman
> Give me all companies that start with "Micro" in Seattle, Washington
>
> Class Diagram Below (The DB Diagram is also the same, where Location
> has a companyID referencing a Company)
> +---------+
> | Company |
> +---------+
> |1
> |
> |1..*
> +----------+
> | Location |
> +----------+
>
>
> "Company is located at location X. Company has at least one location."
> "Location belongs to Company X"
What you really have here at the OOA/D level is:
[Client]
| 1
|
| R1
|
| gets locations from
| *
[Company]
| 1
|
| R2
|
| has
| *
[Location]
and the Client needs access to locations for a particular Company. To
do that the Client must navigate the R1 -> R2 relationship path. [I am
clarifying this here because relationships are crucial to the answer to
your question.]
>
>
> The company class implements the association through
>
> Class Company
> {
> String companyName;
> Set locations;
>
> public void addLocation(location)
> {};
> }
What language is this? In particular, is Set a reference or an
embedded object?
In this case I would argue that it should be a reference. The
addLocation method is really a responsibility of Set, not Company. Any
client should collaborate directly with Set to maintain the relationship.
Class Company
{
String companyName;
Set* myLocations; // C++ style reference
public Set* getCompanyLocationSet()
}
This is better but not good for reasons I will get to below.
Here is where relationships come into the picture. The key thing to
understand is that relationships are really orthogonal to class
semantics. (In fact, commercial code generators for UML models treat
them like aspects.) So one wants to provide decoupling by treating
relationships separately from the class semantics and routine
collaborations needed to solve the problem in hand.
There are three aspects to relationships: implementation, instantiation,
and navigation. Here Set* represents a particular implementation of the
relationship at OOP time (one of several possible) through a collection
class and a reference. Thus at OOP time we have expanded the OOA/D
model to:
[Client]
| 1
|
| R1
|
| gets locations from
| *
[Company]
| 1
| organizes locations for
|
| R3
|
| 1
[Set]
| 1
|
| R2
|
| collects
| *
[Location]
The relationship is instantiated in a complex fashion requiring multiple
steps. It starts when a [Set] instance is created for the Company in
hand and the R3 relationship is instantiated by setting the myLocations
pointer. It continues as [Location] objects are added to that collection.
The navigation of the relationship path is now more complicated. A
Client object must traverse R1 -> R3 -> R2. To do that the Client must
obtain the R3 collection reference from the Company in hand via
getCompanyCollectionSet. It then navigates R2 by asking [Set] to
provide a <new and temporary> collection of [Location] references that
satisfy the selection criteria (starting with "Micro"). So we really
have is:
1 current locations for
[Client] --------------------------+
| 1 |
| |
| R1 |
| |
| gets locations from |
| * |
[Company] |
| 1 |
| organizes locations for | R4
| |
| R3 |
| |
| 1 | 0..1
[Set] [Set]
| 1 | 1
| |
| R2 |
| | R5
| collects |
| * |
[Location] ------------------------+
* collects
where the Set for R3 instantiates the Set for R4 and its relationships.
Typically, that will be implemented and instantiated by simply having
[Set] return a Set* to the Client when asked to select locations.
Now this is all quite tedious to draw in UML so we would only have the
first diagram and the rest would be done at OOP time directly in the
code. However, it is important to understand what is really going on.
In particular, that [Set] becomes a peer class at OOP time to [Client],
[Company], and [Location]. That allows us to decouple the relationship
path semantics from the class semantics. Why is that important?
Suppose during future maintenance one decides to collect locations into
sales regions. Now we have:
[Client]
| 1
|
| R1
|
| gets locations from
| *
[Company]
| 1
| organizes regions for
|
| R3
|
| 1
[Set]
| 1
|
| R6
|
| collects
| *
[Region]
| 1
| organizes locations for
|
| R7
|
| 1
[Set]
| 1
|
| R2
|
| collects
| *
[Location]
Since [Client] is still collaborating on a peer-to-peer basis with
[Location], all we need to change is the way the path is navigated. In
principle, that should be trivial to do as all we have to add is the
navigation of the region set. However, when we do that we discover that
Company::getCompanyLocationSet is not properly named. It should really
be Company::getCompanyRegionSet now.
The problem here is that we have hard-wired the relationship
organization into the semantics of the Company class and that is
reflected in the name of the interface method. This example is pretty
trivial and it would be no big deal to fix. One reason it would be no
big deal is because the various [Set] collections are not hard-wired
into the implementation of [Company] and [region]. In principle we do
not need to touch the implementation of [Company] semantics; we just
need to reassign pointers.
This kind of problem with the name can be manifested in very subtle ways
in more complex situations. For example, suppose the maintainer decided
to leave getCompanyRegionSet and have it do the navigation R6 -> R7 ->
R2. This might be justified because it "hides" the complexity of
regions and locations from [Client]. The problem is that it trashes the
cohesion of [Company]. That's because now we have hard-wired that
navigation into the implementation of the [Company] method. So if the
path changes again we will have to go into the implementation of that
method in [Company] to fix things up. But [Company] really shouldn't
know or care anything about what is going on 2-3 objects away.
So what one really wants is something like Company::getR1SetReference
(or something similarly generic to reflect Client's overall goal) to
access the proper [Set] for that step of the navigation. Now one
doesn't need to touch anything in the [Company] implementation when the
navigation path changes. Now the only place where the new organization
needs code changes is in [Client] where the the original collaboration
is initiated. And even there, it is essentially orthogonal to [Client]
semantics and is treated as an idiom.
However, there is another reason one wants to make relationship
navigation orthogonal to class semantics, which segues to...
>
>
> ******The part that gets me is this.
>
> The typical search in this scenario is
>
> Give me all companies that start with "Micro" in Seattle, Washington
>
> This means that the search is across two classes - Company AND Location
>
> ************************
>
> In the database world, this is a simple join across two tables.
>
> *************************
OO applications solve particular customer problems while RDBs are
designed to provide persistence access that is independent of why the
data is needed. As a result one employs quite different paradigms for
dealing with relationships. So there are no joins in OO applications.
Instead one "walks" individual links in relationship paths. Why?
One answer is performance. Unlike RDBs, where relationships are defined
and instantiated at the Table level for all tuples of the table, OO
relationships are defined at the object level (tuple, if you will).
That means that when searching for "Micro" you will have a smaller set
for any given Company to search.
In fact, the OO paradigm for instantiating relationships often allows
one to avoid searches altogether. That's because the solution is
tailored to a particular problem. So if the only subset of [Location]
that is ever of interest to the problem solution is those locations
starting with "Micro", one would create a separate collection for those
entries that begin with "Micro". When needed one would have only those
locations available for collaboration. That collection could easily be
created by testing each member of Set::add to see if if began with
"micro" and dumping it in the subset collection. Then no search is
needed at all. This sort of instantiation is ubiquitous in OO
applications so that one very rarely ever sees a FIND WHERE construct.
Again, that is only possible because the application is tailored to a
particular problem.
However, the most important reason why one wants to manage relationships
as binary steps in a path is for managing state variables. By limiting
access to objects that can be reached to those that are related to a
particular object, one greatly reduces access to the state variables
(knowledge attributes) in the application. In effect, instantiating
relationships at the object level is how the OO paradigm eliminates the
problems of global data from procedural development. One effectively
provides static structure to enforce business rules and policies about
data access.
One can't do that very well in an RDB because the constraints one wants
to enforce are usually limited to particular problems and that would
compromise the generic access that is crucial to RDB persistence.
The price one pays for the decoupling of relationships and using static
structure to enforce business rules on access is that one needs to
explicitly write the code to navigate the relationships paths piecemeal.
Fortunately, doing that is essentially idiomatic once one is used to
it, so experienced developers rarely even think about it. [It also
makes writing code generators for UML models much easier. B-)]
>
> I've spent several hours on the lists, and have read a number of posts
> that reference the same issue, but came across none that answered it
> practical terms.
>
> So I'd like to preface the question by saying that if the only
> persistence model available to use was an RDBMS and OO was the only
> design methodology. Given that, what is the best methodology for
> solving the problem.
>
> What is the correct correlation of this in a Object Oriented World.
>
> 1) Do I create another class called CompanyLocations that does the
> search and creates the objects as needed. This doesn't work too well in
> my opinion as the relationship does extend further to Locations have
> Employees...would this mean that I would need a CompanyLocationEmployee
> Class for searches?
Possibly. It depends on how important finding locations is to the
overall problem, how likely it is that things may change in the future,
and how complicated the search criteria is. If it is important,
complex, and/or the paths may be volatile, then a separate object to
navigate the paths may be justified on the basis of encapsulating
important and complex business rules.
For example, a common situation is:
[Client]
| *
|
| R1
|
| accesses
| 1
[Tree]
| 0..1
|
| R2
|
| rooted at
| 1 0..1 child of
[Node] -------------------+
| 0..* |
| parent of |
| | R3
+----------------------+
[Node] and its relationships represent a classic model of any
hierarchical tree fanning out from a root node. For various reasons it
may be desirable to hide the navigation rules (e.g., binary tree vs.,
B-Tree) from [Client]. So one introduces [Tree] to do the grunt work of
navigating the relationships.
However, I suspect here your answer would lie in providing collection
classes that were peers of [Company] and [Location] at the OOP level.
>
>
> 2) Do I create a method search() in COmpany that returns all Companies
> that start with "Micro" and then loop through these to search for
> locations that match Seattle, WA?
Collection classes make ideal repositories for such searches. That is,
the search will usually depend upon the organization of the collection,
so the collection itself if the logical "owner" of such algorithms.
>
> 3) Do I fudge the Object Orientation, in Company and create a
> search(companyName, city, state) method that searches across the
> tables? And creates the necessary location instances as well?
No. [Company] should know as little about [Locations] and how they are
organized as possible to reduce implementation dependencies. It may
need to collaborate with [Location], but that will be within the context
of its own responsibilities, not [Client]'s.
>
> 4) Am I making a mountain out of a mole hill?
Not really. One could argue that relationships are one of the most
fundamental distinguishing characteristics of the OO paradigm. Your
questions strike at the heart of issues like cohesion, decoupling, and
encapsulation. (Which why I belabored the basics so much.)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
Alfredo Novoa
wrote:
>What is the best way to implement the following search
>
>Give me all companies that start with "Micro" in Seattle, Washington
select * from Companies where Name like 'Micro%' and City = 'Seattle'
and State = 'Washington"
>******The part that gets me is this.
>
>The typical search in this scenario is
>
>Give me all companies that start with "Micro" in Seattle, Washington
>
>This means that the search is across two classes - Company AND Location
>
>************************
>
>In the database world, this is a simple join across two tables.
>
>*************************
That's why OOAD is not appropriate for business systems (it is too
primitive). Don't use it!
On the other hand, you only need a table.
>So I'd like to preface the question by saying that if the only
>persistence model available to use was an RDBMS and OO was the only
>design methodology.
RDBMS is not a persistence model. RDBMS is a set of data management
tools. Persistence is only one of the many services it provides. OOAD
is not apropriate for business systems.
>Given that, what is the best methodology for
>solving the problem.
To use a RDBMS to manage the data, and to build applications to
present the data and to communicate with users.
>4) Am I making a mountain out of a mole hill?
Indeed, just execute a trivial SQL statement.
Regards
Alfredo
Alfredo Novoa
Hi,
Ignore Lahman, he is a rock headed ignorant. We don't need all that pap
for a trivial query.
Regards
Alfredo
H. S. Lahman
> Ignore Lahman, he is a rock headed ignorant. We don't need all that pap
> for a trivial query.
The OP asked a very fundamental question about OO development. It is
sad that this is the best you can do as a rebuttal to my response. But
that isn't surprising since you have demonstrated repeatedly that you
know virtually nothing about OO development.
Why are you DBMS trolls wasting peoples' time on an OO development
forum? Go find a CRUD/USER/RAD forum.
Patrick May
> Ignore Lahman, he is a rock headed ignorant. We don't need all that pap
> for a trivial query.
Hello,
I strongly recommend that the original poster ignore Mr. Novoa's
opinion. Mr. Lahman has consistently provided valuable responses and
interesting views in this forum, clearly based on extensive
experience. His background as a 'translationista' is somewhat
unusual, making his perspective even more valuable whether or not one
happens to agree with particular points.
Sincerely,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
Patrick May
> What is the best way to implement the following search
>
> Give me all companies that start with "Micro" in Seattle, Washington
Sorry for coming in late here. What is the context in which you
need to execute such a search? There are some techniques to do this
in an OO or functional manner, but if you really need ad hoc reporting
then you should consider just using SQL.
[ . . . ]
> 1) Do I create another class called CompanyLocations that does the
> search and creates the objects as needed. This doesn't work too well
> in my opinion as the relationship does extend further to Locations
> have Employees...would this mean that I would need a
> CompanyLocationEmployee Class for searches?
That would be non-optimal both for the reasons you state and
because you wouldn't be taking advantage of either the relational or
the OO approach.
> 2) Do I create a method search() in COmpany that returns all
> Companies that start with "Micro" and then loop through these to
> search for locations that match Seattle, WA?
That doesn't seem to be the appropriate place for a search()
method. If you were going to take that approach, I'd suggest looking
at the Factory pattern.
> 3) Do I fudge the Object Orientation, in Company and create a
> search(companyName, city, state) method that searches across the
> tables? And creates the necessary location instances as well?
Again, the Company class doesn't seem like the right place for
that method.
> 4) Am I making a mountain out of a mole hill?
With all due respect, I suspect that may be a possibility. ;-)
Use the right tool for the job and don't worry so much about
paradigm purity.
Regards,
Alfredo Novoa
Lahman is the perfect guy when you want to spend many million dollars
in software for a candy shop. I believe he has an extensive experience
maximizing budgets.
Plonk.
Laurent Bossavit
> 2) Do I create a method search() in COmpany that returns all Companies
> that start with "Micro" and then loop through these to search for
> locations that match Seattle, WA?
Yet another option is to use a two-way association, so you can ask a
Location what Companies are associated with it.
Then your search scenario consists of looking up Seattle, WA from the
list of Locations, looping over the list of Companies at that Location
and retaining those whose name starts with "Micro".
Laurent
topmind
Patrick May wrote:
> "Richie" <richie....@gmail.com> writes:
> > What is the best way to implement the following search
> >
> > Give me all companies that start with "Micro" in Seattle, Washington
>
> Sorry for coming in late here. What is the context in which you
> need to execute such a search? There are some techniques to do this
> in an OO or functional manner, but if you really need ad hoc reporting
> then you should consider just using SQL.
>
But then consultants couldn't make big bucks charging for
complexificonvoluted navigational/OOP queries. :-P
-T-
Alfredo Novoa
>But then consultants couldn't make big bucks charging for
>complexificonvoluted navigational/OOP queries. :-P
And the CIOs couldn't make big bucks receiving commisions.
Many consultants don't realize that their managers are exploiting their
incompetence to fraud.
Regards
Alfredo
Bart Wakker
> Hi all,
>
> What is the best way to implement the following search
>
> Give me all companies that start with "Micro" in Seattle, Washington
>
> Class Diagram Below (The DB Diagram is also the same, where Location
> has a companyID referencing a Company)
> +---------+
> | Company |
> +---------+
> |1
> |
> |1..*
> +----------+
> | Location |
> +----------+
>
Well in the end your search will be just the same simple join across
two tables. The question is how you embed this search in an OO
program.
I think it is not good (we learned in a big project the hard way) to
embed data access in your model classes. You need some service
oriented approach for that such as data access objects (DAO). So why
not write a service that contains a Collection
findCompany(CompanyFilter f) method? The CompanyFilter class exists to
define your search criteria, in this case a set of locations and a
name pattern.
The way you implement the method depends on your environment and if
you're using some object relational mapping tool (ORM).
We are using hibernate in java, to map classes and the relations
between these to tables. In that case, it is wise to use the query
language that comes with the tool (in this case, HQL) for such queries
if you can, to avoid duplication in mapping classes to tables. HQL
would generate just the same join that you would write by hand. If
you're not using any tools, then just embed the SQL as you would write
by hand.
> 1) Do I create another class called CompanyLocations that does the
> search and creates the objects as needed. This doesn't work too well
> in my opinion as the relationship does extend further to Locations
> have Employees...would this mean that I would need a
> CompanyLocationEmployee Class for searches?
Create some CompanyService (or CompanyDAO depending on your taste)
class that contains a method findCompany. It may also persist and
retrieve individual Company instances by primary key (if you don't
already have some ORM tool taking care of this).
> 2) Do I create a method search() in COmpany that returns all Companies
> that start with "Micro" and then loop through these to search for
> locations that match Seattle, WA?
No!
>
> 3) Do I fudge the Object Orientation, in Company and create a
> search(companyName, city, state) method that searches across the
> tables? And creates the necessary location instances as well?
No!
Again, I strongly recommend against mixing data access (including
simple loading/persisting but also searching) into your model
classes. Use data access objects instead.
Bart Wakker
> as the lack of replies indicates, there are no good solution for
> your problem. OOA/D does not provide any tools for non-trivial
> searches like your. Using OOA/D, the standard solution would be to
> create a findByNameStartingWithAndByLocation()-method in the Company
> class. The implementation of the find-method would use SQL.
Rasther to create this method on a CompanyDAO class, not on the
Company class itself.
fre...@gmail.com
Fredrik Bertilsson
http://moonbird.sourceforge.net
fre...@gmail.com
> define your search criteria, in this case a set of locations and a
> name pattern.
How would CompanyFilter look like? Wouldn't you finally end up with a
generic Filter class similary to this:
new Filter(new And(Like("name", "micro%"), new Equals("location",
"Seattle")))
> In that case, it is wise to use the query
> language that comes with the tool (in this case, HQL)
Or SQL. HQL and SQL are almost identical.
Fredrik Bertilsson
http://moonbird.sourceforge.net
Patrick May
>> Sorry for coming in late here. What is the context in which you
>> need to execute such a search? There are some techniques to do this
>> in an OO or functional manner, but if you really need ad hoc reporting
>> then you should consider just using SQL.
>
> But then consultants couldn't make big bucks charging for
> complexificonvoluted navigational/OOP queries. :-P
Want some cheese with that whine? ;-)
You should post a list of the companies that hire those
consultants. I'm not averse to standing in the flow of a fool being
parted from his money. All of my clients seem to want real,
measurable value in exchange for their cash.
Sincerely,
Richie
it drink some beer and read it a few times. It is something that I have
been struggling with for a few years and have tried various approaches
to. None of which I have been happy with. Will get back with follow on
questions.
Thanks again
Richie
Richie
that I can look up for examples on how to create the filter class,
store object data etc?
Any books that refer to the problem of mapping object persistence to
relational data?
Why would it be bad to make the objects be responsible for storing
their own state?
Do you think it would be safe to introduce Hibernate in to a middle of
a project? Does it have a steep learning curve and many gotcha's?
Thanks again
Richie
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> >> Sorry for coming in late here. What is the context in which you
> >> need to execute such a search? There are some techniques to do this
> >> in an OO or functional manner, but if you really need ad hoc reporting
> >> then you should consider just using SQL.
> >
> > But then consultants couldn't make big bucks charging for
> > complexificonvoluted navigational/OOP queries. :-P
>
> Want some cheese with that whine? ;-)
>
> You should post a list of the companies that hire those
> consultants. I'm not averse to standing in the flow of a fool being
> parted from his money. All of my clients seem to want real,
> measurable value in exchange for their cash.
Maintenability of software design is very tough to measure objectively.
If it wasn't we wouldn't have so many paradigm wars here. Because of
this, software customers tend to focus on what *is* easy to measure or
see, such as how pretty the screens are.
>
> Sincerely,
>
> Patrick
-T-
Bart Wakker
>> findCompany(CompanyFilter f) method? The CompanyFilter class exists to
>> define your search criteria, in this case a set of locations and a
>> name pattern.
>
> How would CompanyFilter look like? Wouldn't you finally end up with a
> generic Filter class similary to this:
>
> new Filter(new And(Like("name", "micro%"), new Equals("location",
> "Seattle")))
>
e.g.
class CompanyFilter {
String name;
boolean nameUseLike;
boolean nameCaseSensitive;
Set<Location> locations;
}
if all your searches may use like, you can omit the boolean of course,
just document the semantics of your search in the find-method and/or
CompanyFilter class.
>> In that case, it is wise to use the query
>> language that comes with the tool (in this case, HQL)
> Or SQL. HQL and SQL are almost identical.
Indeed, but if you already use some product (e.g. hibernate) to map
your classes and properties to DB tables and attributes, it is nice to
reuse this mapping in your query language. Now if I modify some column
name, I only need to modify my mapping file (one place) and not also
20 queries all over the place.
Bart Wakker
> Seems relatively straight forward...do you know of any web resources
> that I can look up for examples on how to create the filter class,
> store object data etc?
The filter class: just make some class that holds the filter criteria
you need. In your case, you seem to need a set of locations and a
company name, so make a class with those properties and some
getters/setters (depending on the style you like).
>
> Any books that refer to the problem of mapping object persistence to
> relational data?
>
You might focus on some good book on object relational mapping. I must
admit I haven't read any generic books on the subject myself, but
several reference books/manuals on specific ORM products. It gives you
a good idea on what to do and why it makes sense. I recommend, even if
you're not using Java, some documention on Hibernate. Hibernate is a
very practical tool (it didn't defeat the de-jure standard EJB2 for
nothing and established itself as de-facto standard in the java world
and kind of was the basis for EJB3 persistence). Reading books or even
the reference manual on it will is an excellent introduction to the
subject in general: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/
> Why would it be bad to make the objects be responsible for storing
> their own state?
You make your "entity" classes technology dependant. Even though I
love the persistence product we're using, I don't want us to be 100%
dependant on it. Especially I think it should be possible to reuse the
core business logic in different environments, e.g. use it as a
library in an environment that doesn't use the database persistence
but maybe uses some other forms (serialization, xml, ebj) or none at
all for test cases and simulations.
>
> Do you think it would be safe to introduce Hibernate in to a middle of
> a project? Does it have a steep learning curve and many gotcha's?
You can try it carefully, it is what we have done. In an existing very
large project we began to use Hibernate for some very small pieces of
new functionality, just to get a feeling for it and see for ourselves
if it makes sense or not.
The learning curve is not steep, just read this manual, in 2 hours
you'll know quite a bit about it. However, there are some gotcha's and
pitfalls. There is a good FAQ and forum however. We are currently
using it for a very large project (50 developer manyears till now and
at least 100 more manyears to come) in a very large company and are
basing all our databas access upon it (the small pieces where we tried
it out was a previous project, in this new project we started fully
using it). Paid support is available, however we don't use it (in fact
I think we should since I'm the only one in this project that deeply
knows the product, i.e. I'm a single point of failure).
fre...@gmail.com
> String name;
> boolean nameUseLike;
> boolean nameCaseSensitive;
> Set<Location> locations;
>}
Lets say I also want to be able to search companies by the name of the
CEO or by phone number, should I make a CompanyFilter2 class, or mix it
into the first one. How can the method interpreting the CompanlyFilter
know if it should apply "and" or "or"?
> Now if I modify some column
> name, I only need to modify my mapping file (one place) and not also
> 20 queries all over the place.
But if you modify a property name, you have to modify 20 HQL queries
all over the place. Do you have any particular reason for modifying a
database column name?
Fredrik Bertilsson
http://moonbird.sourceforge.net
fre...@gmail.com
>> their own state?
> You make your "entity" classes technology dependant. Even though I
> love the persistence product we're using, I don't want us to be 100%
> dependant on it.
dependent of any specific product.
> environment that doesn't use the database persistence
> but maybe uses some other forms (serialization, xml, ebj) or none at
> all for test cases and simulations.
Testing an average enterprise application without actually using the
database is almost useless. For some applications that only makes minor
use of a database, this might be possible, but trying to replace the
database an application such as SAP R/3 with XML or EJB, and make a
relevant test, would be almost impossible, whatever architecture you
are using.
Fredrik Bertilsson
http://moonbird.sourceforge.net
Bart Wakker
> Why???
See my previous post. If you mix your data access code (technical)
with your business logic (the model class) you may get problems in the
future and limit the usefullness of your business logic code.
Why should an entity (e.g. Person) know how it is persisted? Maybe the
entity may be persisted in a number of ways and in a number of
contexts. Maybe Person instances belonging to some class (e.g. Course
containing Persons) is stored in a different table or even different
technology as a Person belonging to some other class. Persisting is
not a business relevant method. From a non-technial point of view the
whole application might not use database storage at all for example.
Bart Wakker
>> You make your "entity" classes technology dependant. Even though I
>> love the persistence product we're using, I don't want us to be 100%
>> dependant on it.
> Using an interface such as JDBC and using ANSI SQL, you will not be
> dependent of any specific product.
You're still dependent on a database supporting SQL. And your trust in
the universality of ANSI SQL is too big :).
>
>> environment that doesn't use the database persistence
>> but maybe uses some other forms (serialization, xml, ebj) or none at
>> all for test cases and simulations.
> Testing an average enterprise application without actually using the
> database is almost useless. For some applications that only makes minor
> use of a database, this might be possible, but trying to replace the
> database an application such as SAP R/3 with XML or EJB, and make a
> relevant test, would be almost impossible, whatever architecture you
> are using.
I'm talking about unit tests here, not about integration tests. If we
could not use unit tests without database in our project, I tell you,
we'd need ten times as much time.
Also I don't claim that it is realistic that you can port your whole
product to some other mechanism very easily, but at least you can:
- do it more easily
- use PARTS of your code as a library in various environments
Alfredo Novoa
Regards
Alfredo
fre...@gmail.com
market share of SQL databases is more than 95%.
> And your trust in the universality of ANSI SQL is too big :).
I am currenly working with a large HRM application supporting multiple
database vendors. I think it is less than 1% of the SQL statements that
has to be vendor specific. As long as you don't use stored procedures,
it is not very difficult to write vendor neutral SQL statements.
> If we could not use unit tests without database in our project, I tell you,
> we'd need ten times as much time.
Why? Maybe you should use a faster or ligther database installed on the
same server as the application. Many times, slow responses from the
database are caused by a slow network.
> do it more easily
Separating database access from the rest of the application is not
always easy.
> use PARTS of your code as a library in various environments
Most business logic in an enterprise application depends heavily on the
database schema, regardless you try to hide it or not.
Fredrik Bertilsson
http://moonbird.sourceforge.net
fre...@gmail.com
no idea of how a person will be persisted on disk (flat files, indexes,
etc). It may not be persisted at all (all-in-RAM database). Even if
persistence is not needed, the query and transaction features of a
RDBMS would still be useful.
> Maybe Person instances belonging to some class (e.g. Course
> containing Persons) is stored in a different table or even different
> technology as a Person belonging to some other class.
In that case the database would not be normalized. Can you show how
your class diagram and database model would look like in this case?
> Persisting is not a business relevant method.
That is one of the reason you use a RDBMS. It does the job for you.
> From a non-technial point of view the whole application might not use database
> storage at all for example.
There are many applications - FTP clients, word processors, etc - that
don't need a database. But for applications that need one - payroll
processing, stock management - there are no point in hiding the it.
Fredrik Bertilsson
http://moonbird.sourceforge.net
Bart Wakker
>> do it more easily
> Separating database access from the rest of the application is not
> always easy.
We do it in a large project.
>
>> use PARTS of your code as a library in various environments
> Most business logic in an enterprise application depends heavily on
> the database schema, regardless you try to hide it or not.
It is possible and not hard. products like hibernate (ORM) help you
greatly to achieve it.
If your focus is on OO development, you should strive to not depend on
the database schema, but instead to have the database schema depend on
your (OO) design. Of course this approach does not always make sense,
e.g. in a reporting system you'd better not. But in many other cases
it does.
So I'm not claiming that all designs in the world should be object
oriented, but if you try, IMHO it is a very very bad idea to mix
persistence into your model classes.
Bart Wakker
>> From a non-technial point of view the whole application might not
>> use database storage at all for example.
> There are many applications - FTP clients, word processors, etc -
> that don't need a database. But for applications that need one -
> payroll processing, stock management - there are no point in hiding
> the it.
We work on a banking system that updates client portfolio
holdings. Sometimes, client positions are for 'local' client which are
stored in our database. Sometimes, they are simulated or external
clients that are not stored but sent back through mq series
instead. Really, putting code for client portfolios and positions to
persist themselves would be completely inappropriate. It has to be
done by some external mechanism (in case Hibernate for locally
'persistent' instances, and other mechanisms for mq series, ejb
session beans and also files for some batch processing cases).
Mikito Harakiri
> So I'm not claiming that all designs in the world should be object
> oriented, but if you try, IMHO it is a very very bad idea to mix
> persistence into your model classes.
Database is your data model. Relations are logical propositions about
the business that you model. The "persistence" stuff is irrelevant.
Classes and object are irrelevant either. Why people like you who have
no clue about data fundamentals are allowed to design a business system
is a great mystery to me.
Bart Wakker
Is this comp.object or comp.databases.theory?
It looks like this group is inhabited merely by adversaries of object
oriented methodologies? I always consider myself to have a moderate
position somewhere in the middle, when discussing with the OOA/OOD
gurus/architects in my current and previous companies that regard a
database as mere persistence.
If you ask 10 methodology guru's like usually get 10 answers.
However I am quite surprised that of all groups, in comp.object there
seems to be a very strong anti-OO sentiment. How come, have you guys
scared away all of them?
Bart Wakker
By the way. What counts is results and a succesfully running system. I
have seen large projects fail that were either completely data-model
driven or completely OO driven. You need to step back a bit and find
the right balance. All systems I have designed, the largest to date
consisting of 3 years time 50 people (150 man years) have been
delivered on time and exceeded the business requirements and
expectations, so you might be a bit less arrogant and less quick in
you judgement. You have "no clue" about me and have no clue about big
systems if you advocate mixing persistence through all parts of your
system.
Dmitry A. Kazakov
> Is this comp.object or comp.databases.theory?
>
> It looks like this group is inhabited merely by adversaries of object
> oriented methodologies? I always consider myself to have a moderate
> position somewhere in the middle, when discussing with the OOA/OOD
> gurus/architects in my current and previous companies that regard a
> database as mere persistence.
>
> If you ask 10 methodology guru's like usually get 10 answers.
No, usually it so that any 2 gurus give 3 answers. You can figure out how
many it will be in the case of 10 gurus... (:-))
> However I am quite surprised that of all groups, in comp.object there
> seems to be a very strong anti-OO sentiment. How come, have you guys
> scared away all of them?
People are just get tired on ever going RM vs. OO battle. You can look back
in comp.object archives. Basically nobody considers claims of RM-folks
seriously. Because, IMO, it is quite obvious that technically RM is nothing
but specialized containers. One cannot close this discussion forever,
because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
give up their home-brewed philosophies and calmly discuss things in formal
(=language) terms. [ 2) implies 1) and 1) does 2) ]
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Alfredo Novoa
>Why people like you who have
>no clue about data fundamentals are allowed to design a business system
>is a great mystery to me.
This is easy to explain. Most managers don't have a clue either, and
many of them prefer to sell 150 man years than 30.
Regards
Alfredo
fre...@gmail.com
So you according to you the relational model is a subset of the OO
model?
Fredrik Bertilsson
http://moonbird.sourceforge.net
Dmitry A. Kazakov
>> is quite obvious that technically RM is nothing but specialized containers.
>
> So you according to you the relational model is a subset of the OO
> model?
Short answer is yes.
A long one is that OOPLs need a lot of improvements to swallow RM. It could
also happen the opposite. Somebody like Date would finally come up with a
language where, say, tables, rows and columns would have proper types (with
all consequences to follow).
Basically I just don't care who will be the first to make a sane abstract
data type system. (Maybe functional guys? (:-))
S Perryman
news:1147415743.8...@j73g2000cwa.googlegroups.com...
>> is quite obvious that technically RM is nothing but specialized
>> containers.
> So you according to you the relational model is a subset of the OO
> model?
In a way, this is true.
The relational model usually operates on tuples (a,b,c ... ) , where a/b/c
are
primitive values defined as appropriate.
An object can also be considered as an instance of a tuple (where the
tuple defines the properties of the type) .
The major difference IMHO between it and the relational model is
*behaviour* . The value of 'a' might not be a primitive value (123, "fred"
etc) , but an *operation* capable of generating the primitive value.
So in this vein, the RM becomes a degenerate case (where the tuple
elements are actually values, not operations that generate the values) .
All other aspects (selection, projection, join etc) will be the same.
In terms of implementation, the thing that can do both of the above very
easily IMHO is Functional Programming (referential transparency, lazy
evaluation etc) .
Regards,
Steven Perryman
Alfredo Novoa
Steven Perryman wrote:
>The relational model usually operates on tuples (a,b,c ... ) , where a/b/c
>are
>primitive values defined as appropriate.
This is a common mistake. The Relational Model operates on relations
and relations are sets of tuples (a,b,c ... ) , where a/b/c are values
of any kind, relations and tuples included. These values are a superset
of OO objects.
>An object can also be considered as an instance of a tuple (where the
>tuple defines the properties of the type) .
This is a monumental mistake, objects are a subset of your a/b/c
values. Objects are encapsulated (scalar values) while tuples have
visible components. For instance a tuple of grade 2 is known as a pair,
a tuple of grade 3 is known as a triplet, etc.
>The major difference IMHO between it and the relational model is
>*behaviour* . The value of 'a' might not be a primitive value (123, "fred"
>etc) , but an *operation* capable of generating the primitive value.
A value can not be an operation, this is completely absurd.
Regards
Alfredo
Alfredo Novoa
>Somebody like Date would finally come up with a
>language where, say, tables, rows and columns would have proper types (with
>all consequences to follow).
Date & Darwen came with that a decade ago. See
www.thethirdmanifesto.com
Regards
Alfredo
Alfredo Novoa
I forgot to say that an object is the same as an ordered tuple of grade
1. But of course relational tuples are not ordered tuples.
Regards
Alfredo
Dmitry A. Kazakov
Yes, the third manifesto is what I aimed at. (:-))
Basically it is RM with ADTs, Though types aren't plain sets of values and
values aren't literals etc. But that aside, anyway, the next step would be
sets of types and classes of (as ADTs). That would give you full OO. Add
there subprograms as ADTs and at some point you'll get the Great Union
(OO+functional+RM).
Alfredo Novoa
>Basically it is RM with ADTs, Though types aren't plain sets of values
In TTM types aren't plain sets of values.
> and values aren't literals etc.
Literals are values, etc.
>But that aside, anyway, the next step would be
>sets of types and classes of (as ADTs).
Types, classes and ADTs are all the same.
>That would give you full OO.
But we don't want the bad OO things like pointers exposed to users and
operators bundled with types. TTM already has the few good OO things.
>Add
>there subprograms as ADTs and at some point
TTM has subprograms since the first day.
> you'll get the Great Union
>(OO+functional+RM).
We already have that.
Regards
Alfredo
AndyW
<alfred...@hotmail.com> wrote:
I dont know where you get your OO theory from, but its wrong in my
opinion. I agree with you that a relaton is based on a set of tuples
and far as I am aware a tuple is an unordered set of attribute values
(type and name).
I do not believe that objects can be treated as scalar values, because
simply objects can contain other objects and as far as a am aware,
scalar values do not contain operations which objects do.
Nor do I think that a relation or set of tuples is the same or a
superset of an OO Object because OO Objects are an encapsulation of
a set of attributes which MAYBE scalars and/or may be objects AND the
related behavioural methods that work on those attributes. They key
point is the implicitness of the attached behaviour.
To put it another way an OO Object may contain a tuple, or it may not,
but a tuple cannot contain an OO Object.
Another fundemental problem I find with the theory is that relational
information is represented in concrete data. In OO terms that concrete
data is known as instance data. In OO it is possible to perform a
process known as data abstraction that is used to define a set of
classes that contain the rules for the instance data, the instance
data itself and the behaviour that the data projects [the
implementaion of a set of methods that makes up the behaviour is
called an interface]. As far as I am aware, it is not possible to
store this within a relational database. (Abstractions can be
simulated in a relational database, but this is a different notion).
I think that it would be incorrect to suggest that a 'row' of tuples
in a relational database can be considered an object. One of the
formal definitions of an object is that it must have identity, state
and action. A relational database does not store the action
(behavior) of an object. Instead action can only be associated with
the data by some form of procedural activity. In OO parlence, this
procedural code that acts on sets of data is called a Service and the
data is called Mixins. The reason being is that each item (the code
or the data) when viewed on its own would violate one of the
conditions of having identity/state/action.
And I suspect to break your last theory, in OO I think that a value
can be an operation, and can also be itself a set of operations and
related values. For example the 'square root of a random number' is
itself both a value and an operation.
Also, as far as I know, operations cannot be stored in relational
databases because they are transient - that is, they exist only so
long as the operation takes to be performed, after that you have a
result of an operation (and the result may be stored in a relational
database). In the OO world, an operation (otherwise known as a
method) exists so long as the object that contains it exists and
because objects can be made persistant in OO databses, the methods
themselves can be stored as a values.
While I think relational databases can be modified to simulate many of
the facits of OO databases, their primary role is to allow data
manipulation to occur over large sets of related data, where an OO
Databases role is to perform spacial manipulation on complex patterns.
Both could be leveraged to perform the role of the other, but I
suspect when made to do so, they would be a poor performer in
comparison at the end of the day.
Alfredo Novoa
>>there subprograms as ADTs and at some point
>TTM has subprograms since the first day.
Sorry, I misunderstood this.
You probably mean to pass functions as function arguments. I agree they
might be added at some point and the consequences would be complex and
profound (positive, negative or none of the above :). It could be an
interesting topic for research.
Regards
Alfredo
Alfredo Novoa
S Perryman wrote:
>The major difference IMHO between it and the relational model is
>*behaviour* . The value of 'a' might not be a primitive value (123, "fred"
>etc) , but an *operation* capable of generating the primitive value.
There is not difference between the Relational Model and OO in this.
Nothing prohibites to "store" functions in relational variables, but
the content of such variables would be functions and not values.
In other words: if a relation has a function inside, then it is not a
relation value, it is a relation function.
Regards
Alfredo
Dmitry A. Kazakov
> Dmitry wrote:
>
>>Basically it is RM with ADTs, Though types aren't plain sets of values
>
> In TTM types aren't plain sets of values.
They defined it as a named set of values.
>> and values aren't literals etc.
>
> Literals are values, etc.
Which, first, does not imply the reverse. Then, literals rather denote
values or yield values. They aren't values.
>>But that aside, anyway, the next step would be
>>sets of types and classes of (as ADTs).
>
> Types, classes and ADTs are all the same.
Class is a type, but not every type is a class.
>>That would give you full OO.
>
> But we don't want the bad OO things like pointers exposed to users and
> operators bundled with types. TTM already has the few good OO things.
Pointer type generator is just an operation of types algebra. [TTM calls
them "type generators"] It is not clear why this particular operation
should be excluded. Anyway, pointers can be obtained in any language with
isotropic containers, with all disadvantages of, and none of compiler
checks. TTM has such containers (finally). So it is better to provide
pointers in a natural way.
"Operators bundled with types" is a definition of types. TTM is typed. How
can a system be typed without a relation: type <-> operation of? Note that
TTM explicitly talks about operators "defined on", "associated with" a
given type. To me that's clearly bundled.
>>Add there subprograms as ADTs and at some point
>
> TTM has subprograms since the first day.
You need types of, at least.
>> you'll get the Great Union
>>(OO+functional+RM).
>
> We already have that.
No. TTM is definitely a step in right direction, but it just repeats things
which in universal purpose languages were standard for decades. In my
personal view it is an attempt to get RM out of 4GL disaster, back to
reality of early 80s. Generic programming and polymorphism is ahead.
Alfredo Novoa
>They defined it as a named set of values.
No, this is not the complete definition.
>Which, first, does not imply the reverse. Then, literals rather denote
>values or yield values. They aren't values.
A literal is the textual representations of a value, but this is
completely irrelevant to TTM. TTM only uses the word literal in the BNF
specification, and it is completely correct.
>Class is a type, but not every type is a class.
Class is often reserved to pointer types, but not always.
>Pointer type generator is just an operation of types algebra. [TTM calls
>them "type generators"]
Completely wrong. TTM forbids pointers.
> It is not clear why this particular operation
>should be excluded. Anyway, pointers can be obtained in any language with
>isotropic containers, with all disadvantages of, and none of compiler
>checks. TTM has such containers (finally). So it is better to provide
>pointers in a natural way.
Bullshit. The disadvantages of pointers exposed to users are very well
known.
>"Operators bundled with types" is a definition of types.
No, an operator might belong to several types.
> TTM is typed. How
>can a system be typed without a relation: type <-> operation of?
TTM allows to associate one operator to several types. Here is clearly
more powerful than OO which is restricted to 1-1 relationships.
>TTM explicitly talks about operators "defined on", "associated with" a
>given type.
A given set of types.
>Generic programming and polymorphism is ahead.
TTM supports polymorphism through subtyping, and Darwen proposed very
elegant generic programming extensions to Tutorial D in TTM mail list.
On the other hand TTM never forbid generic programming.
Regards
Alfredo
Alfredo Novoa
>and far as I am aware a tuple is an unordered set of attribute values
>(type and name).
A tuple is a set of ordered pairs (name and value).
An ordered pair is the same as an ordered tuple of degree 2.
>I do not believe that objects can be treated as scalar values
Objects are scalar values when object means value, but it might mean
many other things. Object is an horribly overloaded word unuseful to
communicate.
>, because
>simply objects can contain other objects
Scalar values can contain other scalar values.
> and as far as a am aware,
>scalar values do not contain operations which objects do.
Types contain operators. Scalar and non scalar values have types.
>Nor do I think that a relation or set of tuples is the same or a
>superset of an OO Object
I never said that. I said that tuple attribute values might be objects
(when object means scalar value) and non scalar values.
>To put it another way an OO Object may contain a tuple, or it may not,
>but a tuple cannot contain an OO Object.
This is exactly the contrary.
>Another fundemental problem I find with the theory is that relational
>information is represented in concrete data. In OO terms that concrete
>data is known as instance data. In OO it is possible to perform a
>process known as data abstraction that is used to define a set of
>classes that contain the rules for the instance data, the instance
>data itself and the behaviour that the data projects [the
>implementaion of a set of methods that makes up the behaviour is
>called an interface]. As far as I am aware, it is not possible to
>store this within a relational database. (Abstractions can be
>simulated in a relational database, but this is a different notion).
Have you heard about integrity constraints and derivation rules?
>I think that it would be incorrect to suggest that a 'row' of tuples
>in a relational database can be considered an object.
Row of tuples?
> One of the
>formal definitions of an object is that it must have identity, state
>and action.
Object sometimes means variable, sometimes means value and sometimes
means thing. This is not formal in any way and leads to many mistakes.
The identity of a value is nothing but the value itself. The state of a
variable is the value it contains.
> A relational database does not store the action
>(behavior) of an object.
See, you are completely confused.
A relational database contains all the rules (behavior) of the data in
form of integrity constraints, structure and derivation rules.
> Instead action can only be associated with
>the data by some form of procedural activity. In OO parlence, this
>procedural code that acts on sets of data is called a Service and the
>data is called Mixins. The reason being is that each item (the code
>or the data) when viewed on its own would violate one of the
>conditions of having identity/state/action.
Bullshit.
>And I suspect to break your last theory, in OO I think that a value
>can be an operation, and can also be itself a set of operations and
I disagree, but in that case in a relational database a value can be an
operation. There is no difference.
>related values. For example the 'square root of a random number' is
>itself both a value and an operation.
You are confusing the operation with the result of the operation.
As I said previously, if you put a function into a value then it is not
longer a value, it is a function. Values are immutable.
The Relational Model does not forbid something like this:
INSERT INTO A VALUES(SQRT(function Random()));
>While I think relational databases can be modified to simulate many of
>the facits of OO databases
You probably mean RDBMS and OODBMS.
>, their primary role is to allow data
>manipulation to occur over large sets of related data,
Wrong. Their primary role is to manage data, any kind of data.
> where an OO
>Databases role is to perform spacial manipulation on complex patterns.
OODBMS are a kind of obsolete DBMS. There is nothing that you can not
do better with a RDBMS.
Regards
Alfredo
Dmitry A. Kazakov
>>They defined it as a named set of values.
>
> No, this is not the complete definition.
I saw only this.
[ BTW, the requirement to be named is barely consistent with any types
algebra. The problem is that you cannot compose type operations ("type
generators" in TTM terms), because the results were anonymous, so
technically no types. Ada, for example, faces this problem in many cases,
though it has anonymous types. ]
>>Which, first, does not imply the reverse. Then, literals rather denote
>>values or yield values. They aren't values.
>
> A literal is the textual representations of a value, but this is
> completely irrelevant to TTM. TTM only uses the word literal in the BNF
> specification, and it is completely correct.
This is also technically problematic, because it requires one literal one
value mapping. This excludes overloading. But the main problem is: do
values beyond literals exist? Is it really so that any value is required to
have a literal? It breaks information hiding / abstraction principle.
Structured equivalence is a flawed idea in most cases, anyway.
>>Class is a type, but not every type is a class.
>
> Class is often reserved to pointer types, but not always.
That's a side-effect of some corrupt OOPLs. I define class informally as a
closure of a set types.
Formally: Let you have a set of types T={T1, T2, ...}, then you can
construct a new type "class T" such that its values are ordered pairs. The
first element of the pair is the type tag of the second element, which is a
value of some type from T.
BTW, class defined as above is obviously a relation.
>>Pointer type generator is just an operation of types algebra. [TTM calls
>>them "type generators"]
>
> Completely wrong. TTM forbids pointers.
Yet they explicitly talk about by-value and by-reference parameter passing.
So they admit existence of referential types, which are not types because
they have no names. It is inconsistent, at least.
>> It is not clear why this particular operation
>>should be excluded. Anyway, pointers can be obtained in any language with
>>isotropic containers, with all disadvantages of, and none of compiler
>>checks. TTM has such containers (finally). So it is better to provide
>>pointers in a natural way.
>
> Bullshit. The disadvantages of pointers exposed to users are very well
> known.
So? How are you going to get by-reference parameter passing and recursive
types?
>>"Operators bundled with types" is a definition of types.
>
> No, an operator might belong to several types.
>
>> TTM is typed. How
>>can a system be typed without a relation: type <-> operation of?
>
> TTM allows to associate one operator to several types. Here is clearly
> more powerful than OO which is restricted to 1-1 relationships.
It is a misunderstanding on your side. OO does not require 1-1
relationships between types and operations. On the contrary. If you have
several parameters / results of different types the operation must be of
each of them.
>>Generic programming and polymorphism is ahead.
>
> TTM supports polymorphism through subtyping,
Without polymorphic values, without naming their types?
> and Darwen proposed very
> elegant generic programming extensions to Tutorial D in TTM mail list.
> On the other hand TTM never forbid generic programming.
It would be very difficult to have holding the position that a subtype is
just a type + constraint. This forces you to present a supertype first with
all its possible values and only then filter out ones you don't need. This
is too weak. How do you spell: "[any] relation between types A and B?" That
is not a type. It is a set of. The whole idea of classes is to bring this
meta level thing down to values. That's impossible to do using constraints.
A polymorphic value isn't specific, per TTM construction: (tag, x) /= x.
So, again, per construction the type T of x isn't a subtype of the class T.
One should get rid of the "is-a" obsession to overwhelm this.
Alfredo Novoa
>>>They defined it as a named set of values.
>> No, this is not the complete definition.
>I saw only this.
Read it again.
>[ BTW, the requirement to be named is barely consistent with any types
>algebra.
I agree on that name is not a requirement.
> The problem is that you cannot compose type operations ("type
>generators" in TTM terms), because the results were anonymous, so
>technically no types.
No, in TTM the results have name, although I don't like that.
>This is also technically problematic, because it requires one literal one
>value mapping. This excludes overloading.
I don't understand you. One literal to several values mapping is an
absurd. Can you give an example?
You probably mean a function instead of a literal.
> But the main problem is: do
>values beyond literals exist?
Of course.
> Is it really so that any value is required to
>have a literal?
This is an absurd question. If you want to represent a value textually
then you need at least one literal.
> It breaks information hiding / abstraction principle.
How?
>That's a side-effect of some corrupt OOPLs. I define class informally as a
>closure of a set types.
And I could define class as a pink elephant. Class is often used as a
synonym of type, but it has many other meanings like conceptual entity.
Class is another terribly overlodaded term unuseful to communicate.
>So they admit existence of referential types, which are not types because
>they have no names. It is inconsistent, at least.
No, TTM type generators generate named value types, and they could
generate named referential types in the same way. But referential types
are forbidden, of course :-)
>So? How are you going to get by-reference parameter passing and recursive
>types?
They were dropped with referential types.
>It is a misunderstanding on your side. OO does not require 1-1
>relationships between types and operations. On the contrary. If you have
>several parameters / results of different types the operation must be of
>each of them.
But the operation needs to be arbitrarily bundled with a single type.
That's the problem TTM solves.
>Without polymorphic values,
What on hell polymorphic values are?
>without naming their types?
Their types have names.
>It would be very difficult to have holding the position that a subtype is
>just a type + constraint.
You define a subtype constrainting a type. This is basic common sense.
type RedApple is Apple where color = red
> This forces you to present a supertype first with
>all its possible values and only then filter out ones you don't need.
Of course. How do you pretend to have red apples if you don't have any
apple?
>How do you spell: "[any] relation between types A and B?" That
>is not a type.
This is an absurd example but that is a type.
> It is a set of. The whole idea of classes is to bring this
>meta level thing down to values. That's impossible to do using constraints.
Of course it is possible. We can define that type constrainting the set
of all relations.
It is clear that you are very confused. OO does not have subtyping at
all. It has a jump table hidding technique called "inheritance" which
has nothing to do with subtyping. Many OO languages have a keyword "is"
which has nothing to do with the english verb "to be".
Regards
Alfredo
S Perryman
news:1147432825....@u72g2000cwu.googlegroups.com...
> Steven Perryman wrote:
>>The relational model usually operates on tuples (a,b,c ... ) , where a/b/c
>>are primitive values defined as appropriate.
> This is a common mistake. The Relational Model operates on relations
> and relations are sets of tuples (a,b,c ... ) , where a/b/c are values
> of any kind, relations and tuples included. These values are a superset
> of OO objects.
Covered my arse by typing "usually" . :-)
But point acknowledged (I haven't degraded the debate IMHO) .
>>An object can also be considered as an instance of a tuple (where the
>>tuple defines the properties of the type) .
> This is a monumental mistake, objects are a subset of your a/b/c
> values. Objects are encapsulated (scalar values) while tuples have
> visible components. For instance a tuple of grade 2 is known as a pair,
> a tuple of grade 3 is known as a triplet, etc.
An object definition (ie type) is a collection of properties.
That definition can be easily represented in tuple form.
As can object instances.
There is no conceptual difference between :
Person = (name: string, age: int)
and
type Person { name: string, age: int }
>>The major difference IMHO between it and the relational model is
>>*behaviour* . The value of 'a' might not be a primitive value (123, "fred"
>>etc) , but an *operation* capable of generating the primitive value.
> A value can not be an operation, this is completely absurd.
An element of a tuple can be an operation (probably bound to a free
variable - the tuple itself perhaps) . All that is required is that if I
have a
tuple (x: int, y: int) , when I do t.y I get an integer value.
Whether y refers to an actual value, or an operation that computes the
value, is irrelevant. In Functional Programming, this is called "referential
transparency" . And it allows the world of behaviour to be joined with
the world of values in a uniform and consistent manner.
Regards,
Steven Perryman
Dmitry A. Kazakov
> Dmitry wrote:
>
>>This is also technically problematic, because it requires one literal one
>>value mapping. This excludes overloading.
>
> I don't understand you. One literal to several values mapping is an
> absurd. Can you give an example?
13 (is it Integer, Day of month, Prime, Odd, Positive, Modular, Octet,
Rational, Real, Complex...?)
'a' (is it ASCII, EBCDIC, UCS-2, UTF-8, Cyrillic, Latin-1...?)
> You probably mean a function instead of a literal.
Yes, literals are functions for that matter. This is why it is unwise to
define types as sets of literals.
>> But the main problem is: do
>>values beyond literals exist?
>
> Of course.
And what about types of?
>> Is it really so that any value is required to
>>have a literal?
>
> This is an absurd question. If you want to represent a value textually
> then you need at least one literal.
That's funny. What about sets of values having cardinalities above aleph-1
(continuum)? You just cannot have all literals of. Should it mean that we
cannot have f:R->R functions as values?
>> It breaks information hiding / abstraction principle.
>
> How?
You can look inside each value and exploit this knowledge.
>>That's a side-effect of some corrupt OOPLs. I define class informally as a
>>closure of a set types.
>
> And I could define class as a pink elephant. Class is often used as a
> synonym of type, but it has many other meanings like conceptual entity.
> Class is another terribly overlodaded term unuseful to communicate.
I gave a precise definition of. It would be sufficient, if you just could
show an equivalent thing in TTM. I found none.
>>So they admit existence of referential types, which are not types because
>>they have no names. It is inconsistent, at least.
>
> No, TTM type generators generate named value types, and they could
> generate named referential types in the same way. But referential types
> are forbidden, of course :-)
>
>>So? How are you going to get by-reference parameter passing and recursive
>>types?
>
> They were dropped with referential types.
Both? You will sell that to nobody.
>>It is a misunderstanding on your side. OO does not require 1-1
>>relationships between types and operations. On the contrary. If you have
>>several parameters / results of different types the operation must be of
>>each of them.
>
> But the operation needs to be arbitrarily bundled with a single type.
Where that follows from? Operations are bound to tuples of types. Operation
is of each type in the tuple.
>>Without polymorphic values,
>
> What on hell polymorphic values are?
Ones, which type is a class. A polymorphic value is a tuple (tag, x). Note
that if you didn't drop referential types, you could use just T instead of
tag of. So it would be (T, x).
>>It would be very difficult to have holding the position that a subtype is
>>just a type + constraint.
>
> You define a subtype constrainting a type. This is basic common sense.
>
> type RedApple is Apple where color = red
Come on, if you want to talk about common sense then what about:
type MyApple is Apple where <a constraint please!>
>> This forces you to present a supertype first with
>>all its possible values and only then filter out ones you don't need.
>
> Of course. How do you pretend to have red apples if you don't have any
> apple?
By growing them on apple trees, my dear!
BTW, I have a strong impression that things sold as "red apples" in nearby
supermarket are in fact potato, painted red. (:-))
Look at set theory. It has more meat than just forall T, P(x) exists
P(T)={x in T | P(x) }
>>How do you spell: "[any] relation between types A and B?" That
>>is not a type.
>
> This is an absurd example but that is a type.
How do you spell it?
>> It is a set of. The whole idea of classes is to bring this
>>meta level thing down to values. That's impossible to do using constraints.
>
> Of course it is possible. We can define that type constrainting the set
> of all relations.
Show me a type generator producing "all relations."
Then again, carefully observe that the set of all relations has *types* as
elements. It is not even a type. According to TTM a type is a set of
values. Even if it were a type (=types were allowed as values), then per
definition any constraint of this set would never give you any subset of
original values (=tuples containing As and Bs). It just does not work. You
have {{(a1,b1),(a1,b2)}, {(a2,b1,c1)}}, but what is needed is
{(a1,b1),(a1,b2),(a2,b1,c1)}.
> It is clear that you are very confused. OO does not have subtyping at
> all. It has a jump table hidding technique called "inheritance" which
> has nothing to do with subtyping.
You should define the term subtyping first. Type + constraint is just one
specific form of subtyping. And OO languages had it for a very long time,
Ada for instance. Practically any language has immutable subtypes.
Alfredo Novoa
>> I don't understand you. One literal to several values mapping is an
>> absurd. Can you give an example?
>13 (is it Integer, Day of month, Prime, Odd, Positive, Modular, Octet,
>Rational, Real, Complex...?)
13 maps to a single value with several types. Something addressed by
TTM and not by OO.
>> This is an absurd question. If you want to represent a value textually
>> then you need at least one literal.
>That's funny. What about sets of values having cardinalities above aleph-1
>(continuum)? You just cannot have all literals of.
Of course, but if you don't have a literal then you don't have a
textual representation. That's why it was an absurd question.
>>>That's a side-effect of some corrupt OOPLs. I define class informally as a
>>>closure of a set types.
>> And I could define class as a pink elephant. Class is often used as a
>> synonym of type, but it has many other meanings like conceptual entity.
>> Class is another terribly overlodaded term unuseful to communicate.
>I gave a precise definition of.
But also arbitrary and unconsensed.
> It would be sufficient, if you just could
>show an equivalent thing in TTM. I found none.
As I said, class is a term to avoid in formal discussions.
>> They were dropped with referential types.
>Both? You will sell that to nobody.
This is a very direct consequence. I don't miss them.
>Where that follows from? Operations are bound to tuples of types. Operation
>is of each type in the tuple.
You are not following me. I am talking about scalar operators
(methods).
For instance in OO if I create an operator which takes parameters of
three different types and returns a value of a fourth type, then I am
forced to bundle the operator with a single type and this is stupid.
>> What on hell polymorphic values are?
>Ones, which type is a class.
Like this?: "Hello"
Definitely we don't speak the same language.
>Come on, if you want to talk about common sense then what about:
>type MyApple is Apple where <a constraint please!>
What is the problem?
>> Of course. How do you pretend to have red apples if you don't have any
>> apple?
>By growing them on apple trees, my dear!
And this will allow you to have red apples without having any apple.
Great!
One needs to break his brain to put OO inside.
>>>How do you spell: "[any] relation between types A and B?" That
>>>is not a type.
>> This is an absurd example but that is a type.
>How do you spell it?
relation between types A and B
>> Of course it is possible. We can define that type constrainting the set
>> of all relations.
>Show me a type generator producing "all relations."
relation()
>Then again, carefully observe that the set of all relations has *types* as
>elements.
Relations are values like any other. The set of all relations might be
defined as a type without any problem. Tutorial D does not define this
type because Date and Darwen don't conseder it useful or convenient but
nothing forbides it.
>You should define the term subtyping first.
A group forming a type within a larger type.
a type that is subordinate to or included in another type <the blood
group subtypes> <subtypes of a disease>
: to classify according to subtype <schizophrenic patients subtyped as
paranoid or catatonic>
http://dictionary.reference.com/search?q=subtype
Regards
Alfredo
Alfredo Novoa
>>>An object can also be considered as an instance of a tuple (where the
>>>tuple defines the properties of the type) .
>> This is a monumental mistake, objects are a subset of your a/b/c
>> values. Objects are encapsulated (scalar values) while tuples have
>> visible components. For instance a tuple of grade 2 is known as a pair,
>> a tuple of grade 3 is known as a triplet, etc.
>An object definition (ie type) is a collection of properties.
It was a mistake on my side to use the term "object". I was assuming
that object meant "value" and not type. If you meant type then your
statement is even more meaningless.
So object sometimes means value, sometimes means variable and sometimes
means type. We only need to call object to operations to completely
mess the key concepts of imperative programming.
>That definition can be easily represented in tuple form.
>As can object instances.
You are mixing apples with oranges.
>There is no conceptual difference between :
>Person = (name: string, age: int)
>and
>type Person { name: string, age: int }
If the first Person is a scalar type and the second Person is a tuple
type there is a conceptual difference.
BTW I don't know any relational language which allows to define tuple
types. Date and Darwen deprecated that feature.
Person(name 'Juan', age 20)
is a singleton
tuple { name 'Juan', age 20 }
is a pair.
Notice that "Person" dissapeared in the tuple.
>An element of a tuple can be an operation (probably bound to a free
>variable - the tuple itself perhaps) .
If you do that what you have is a tuple function. Tuple is the short
for tuple value and values are immutable.
But the question is that there is not any difference between the RM and
OO in this.
>Whether y refers to an actual value, or an operation that computes the
>value, is irrelevant. In Functional Programming, this is called "referential
>transparency" .
Referential transparency is also important in the RM. We discussed the
topic extensively in TTM mail list.
Regards
Alfredo
topmind
> > However I am quite surprised that of all groups, in comp.object there
> > seems to be a very strong anti-OO sentiment. How come, have you guys
> > scared away all of them?
>
> People are just get tired on ever going RM vs. OO battle. You can look back
> in comp.object archives. Basically nobody considers claims of RM-folks
> seriously.
No, it is OO fans that don't take them seriously. The OO fans have
cleverly painted the RM fans as "legacy huggers". The COBOL-like syntax
of SQL helps this picture stay in the heads of naive PHB's. (Liking
relational and liking SQL are two different things. Very few defend SQL
as the best possible relational language.)
> Because, IMO, it is quite obvious that technically RM is nothing
> but specialized containers.
This sounds like the old "OO is better because OO is a superset of RM".
I generally *agree* with this in part. RM imposes rules that OO does
not. These rules provide consistency in design, and OO's lack of
consistency is one of my biggest complaints about it. OO designs are
the modern-day GOTO's: navigational speghetti similar to what motivated
Dr. Codd to fix it.
Note that RM's rules don't necessarily reduce what is possible to
implement. With some procedural tossed in, RM-based designs are turing
complete and not objectively more code than an OO version.
> One cannot close this discussion forever,
> because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
> give up their home-brewed philosophies and calmly discuss things in formal
> (=language) terms. [ 2) implies 1) and 1) does 2) ]
I have concluded that this is largely because software engineering is
mostly about *psychology* and not math nor science. And, everyone's
psychology is different. If you claim that OO makes you more
productive, I won't necessarily disagree; for your brain my simply
inharently fit OO better.
It is the implied assumption that OO is objectively better and thus
should be *forced* on developers that sets me off. I don't want your
personal preferences shoved down my throat, yet this is what the
industry is doing. Java removing formal functions is an example of this
one-paradigm-fits-all thinking. Gosling should be publicly spanked for
that.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
AndyW
<alfred...@hotmail.com> wrote:
You seem to have made quite a few assumptions about Object
Orientation - a few of which are pretty incorrect. This is leading
me to think that you havnt actually been practicing OO in the real
world, but have perhaps formed some opinions based on information
read.
I'm not meaning this as an insult, just an observation because some of
the assumptions made that I've seen in some of your other posts are
pretty basic mistakes in the OO world.
For example, in the next post
quote:
>It was a mistake on my side to use the term "object". I was assuming
>that object meant "value" and not type. If you meant type then your
>statement is even more meaningless.
Anyone with OO experience of any kind would not have made that
mistake. Most OO people should know what 'Type' actually is.
quote
>The identity of a value is nothing but the value itself. The state of a variable is the value it contains.
Again, failure to grasp the basics. The identity is otherwise in OO
parlence known as Type. State refers to the values of all the
attributes at a given point of time. Its a basic OO principle
referenced by Booch back in 1987 (or thereabouts).
Quote
>> A relational database does not store the action
>>(behavior) of an object.
>See, you are completely confused.
>A relational database contains all the rules (behavior) of the data in
>form of integrity constraints, structure and derivation rules.
Rule and Behaviour are two entirely different things in OO. Generally
in OO a rule is implied by its invariant - the action/behaviour is
the actual code that implements that rule. I've never seen code
stored in a tuple in a relational database - stored procedures yes,
but the closest that represents in OO is called a class method - these
are static method in a service class - certainly not OO, but
procedural in nature. The term 'behaviour' in OO refers to the set
of functionality implemented by the objects methods (code functions) -
ie. what the actions actually do.
These are really really basic mistakes you are making. It kind of
invalidates your argument because you are arguing based on incorrect
assumption.
Dmitry A. Kazakov
>>> However I am quite surprised that of all groups, in comp.object there
>>> seems to be a very strong anti-OO sentiment. How come, have you guys
>>> scared away all of them?
>>
>> People are just get tired on ever going RM vs. OO battle. You can look back
>> in comp.object archives. Basically nobody considers claims of RM-folks
>> seriously.
>
> No, it is OO fans that don't take them seriously. The OO fans have
> cleverly painted the RM fans as "legacy huggers".
Well, what you have represented in comp.object as RM, definitely lags
behind somewhere in mid 60s. Others, like C.J. Date, have understood the
role of types, identity, generic programming. They are welcome. [ I cannot
tell if they represent majority and whether majority really understands and
accepts all consequences of bringing types to RM. It does not look so,
after debates RM guys. ]
>> Because, IMO, it is quite obvious that technically RM is nothing
>> but specialized containers.
>
> This sounds like the old "OO is better because OO is a superset of RM".
> I generally *agree* with this in part. RM imposes rules that OO does
> not. These rules provide consistency in design, and OO's lack of
> consistency is one of my biggest complaints about it.
Nobody wants to intentionally propose an inconsistent framework. So to make
a point you should show that RM may not have consistent supersets. [ For
example in mathematics, reals extend integers, complex extend reals, but
the field of complex numbers cannot be extended anymore. ]
>> One cannot close this discussion forever,
>> because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
>> give up their home-brewed philosophies and calmly discuss things in formal
>> (=language) terms. [ 2) implies 1) and 1) does 2) ]
>
> I have concluded that this is largely because software engineering is
> mostly about *psychology* and not math nor science.
That's new to me. Though, the argumentation style of some RM guys (all
these "bullshit", "horseshit" etc) leaves some space to suspicions.
> It is the implied assumption that OO is objectively better and thus
> should be *forced* on developers that sets me off. I don't want your
> personal preferences shoved down my throat, yet this is what the
> industry is doing. Java removing formal functions is an example of this
> one-paradigm-fits-all thinking. Gosling should be publicly spanked for
> that.
Well, programming style is the most important issue for any software firm.
There is nothing worse than bad standard, except that no standard.
... and do you want to abolish Java? Count me in!
Dmitry A. Kazakov
> Dmitry wote:
>
>>> I don't understand you. One literal to several values mapping is an
>>> absurd. Can you give an example?
>
>>13 (is it Integer, Day of month, Prime, Odd, Positive, Modular, Octet,
>>Rational, Real, Complex...?)
>
> 13 maps to a single value with several types.
So 13 shall have same representation for all types it has. That includes
Octet, Int_32 and bignum?
> Something addressed by TTM and not by OO.
I'm not sure about it. I have an impression that the mainstream OO pursues
this same nonsense.
>>> This is an absurd question. If you want to represent a value textually
>>> then you need at least one literal.
>
>>That's funny. What about sets of values having cardinalities above aleph-1
>>(continuum)? You just cannot have all literals of.
>
> Of course, but if you don't have a literal then you don't have a
> textual representation. That's why it was an absurd question.
This is wrong. I cannot have all literals, but I can represent *any* given
value. It is Richard's paradox.
BTW, the requirement of TTM to have literals + equality for all values,
*automatically* excludes functions as values. You can't compare programs.
That's a hard mathematical fact. However, without referential types you
cannot have them anyway.
>>>>That's a side-effect of some corrupt OOPLs. I define class informally as a
>>>>closure of a set types.
>
>>> And I could define class as a pink elephant. Class is often used as a
>>> synonym of type, but it has many other meanings like conceptual entity.
>>> Class is another terribly overlodaded term unuseful to communicate.
>
>>I gave a precise definition of.
>
> But also arbitrary and unconsensed.
?
>> It would be sufficient, if you just could
>>show an equivalent thing in TTM. I found none.
>
> As I said, class is a term to avoid in formal discussions.
It seems that you are trying to escape formal discussion. I gave a formal
definition of a class. You have rejected it without any explanation, and
presented nothing instead.
>>Where that follows from? Operations are bound to tuples of types. Operation
>>is of each type in the tuple.
>
> You are not following me. I am talking about scalar operators
> (methods).
I meant methods.
> For instance in OO if I create an operator which takes parameters of
> three different types and returns a value of a fourth type, then I am
> forced to bundle the operator with a single type and this is stupid.
This is wrong. See multiple dispatch.
>>> What on hell polymorphic values are?
>
>>Ones, which type is a class.
>
> Like this?: "Hello"
"Hello" of the type String is not polymorphic. String is not a class. It
can be used to create a class of types derived from String.
>>Come on, if you want to talk about common sense then what about:
>
>>type MyApple is Apple where <a constraint please!>
>
> What is the problem?
Write the constraint in terms of Apple.
>>> Of course. How do you pretend to have red apples if you don't have any
>>> apple?
>
>>By growing them on apple trees, my dear!
>
> And this will allow you to have red apples without having any apple.
> Great!
Exactly
> One needs to break his brain to put OO inside.
No, one just need to know mathematics. You can construct sets without
having them before. It would be absurd otherwise, or?
>>>>How do you spell: "[any] relation between types A and B?" That
>>>>is not a type.
>
>>> This is an absurd example but that is a type.
>
>>How do you spell it?
>
> relation between types A and B
Which type it has?
>>> Of course it is possible. We can define that type constrainting the set
>>> of all relations.
>
>>Show me a type generator producing "all relations."
>
> relation()
OK, let "relation()" be a type. Which values it has?
> >You should define the term subtyping first.
>
> A group forming a type within a larger type.
> a type that is subordinate to or included in another type <the blood
> group subtypes> <subtypes of a disease>
>: to classify according to subtype <schizophrenic patients subtyped as
> paranoid or catatonic>
>
> http://dictionary.reference.com/search?q=subtype
Should I read it as "subtype" is not defined? Do you see any difference
between English and programming languages?
topmind
Dmitry A. Kazakov wrote:
> On 13 May 2006 16:26:58 -0700, topmind wrote:
>
> >>> However I am quite surprised that of all groups, in comp.object there
> >>> seems to be a very strong anti-OO sentiment. How come, have you guys
> >>> scared away all of them?
> >>
> >> People are just get tired on ever going RM vs. OO battle. You can look back
> >> in comp.object archives. Basically nobody considers claims of RM-folks
> >> seriously.
> >
> > No, it is OO fans that don't take them seriously. The OO fans have
> > cleverly painted the RM fans as "legacy huggers".
>
> Well, what you have represented in comp.object as RM, definitely lags
> behind somewhere in mid 60s.
Kind of hard since RM was not revealed until 1970.
> Others, like C.J. Date, have understood the
> role of types, identity, generic programming. They are welcome. [ I cannot
> tell if they represent majority and whether majority really understands and
> accepts all consequences of bringing types to RM. It does not look so,
> after debates RM guys. ]
I generally consider relational to be orthogonal to "types". Perhaps
Date wants to integrate them, but that is not the only way to go about
it. The "type engine" and the relational engine can be treated
independently as long a the type engine satisfies a minimum set of
requirements. Further, this would allow dynamic or type-free engines
also, which I happen to be a fan of.
I have not heard Date's opinion on independence yet. I generally
assume independence is a good thing because it separates such issues
and allows domain-specific variations. There gillions of potential
"maths" out there and I see no reason to try to hardwire each one to
the relational model.
>
> >> Because, IMO, it is quite obvious that technically RM is nothing
> >> but specialized containers.
> >
> > This sounds like the old "OO is better because OO is a superset of RM".
> > I generally *agree* with this in part. RM imposes rules that OO does
> > not. These rules provide consistency in design, and OO's lack of
> > consistency is one of my biggest complaints about it.
>
> Nobody wants to intentionally propose an inconsistent framework. So to make
> a point you should show that RM may not have consistent supersets. [ For
> example in mathematics, reals extend integers, complex extend reals, but
> the field of complex numbers cannot be extended anymore. ]
I am not sure what you mean. Why would I have to show that RM does not
have consistent supersets when that is not what I claimed?
>
> >> One cannot close this discussion forever,
> >> because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
> >> give up their home-brewed philosophies and calmly discuss things in formal
> >> (=language) terms. [ 2) implies 1) and 1) does 2) ]
> >
> > I have concluded that this is largely because software engineering is
> > mostly about *psychology* and not math nor science.
>
> That's new to me. Though, the argumentation style of some RM guys (all
> these "bullshit", "horseshit" etc) leaves some space to suspicions.
Some RM fans talk about the mathematical background of RM. Following
math alone is no guarentee of utility, however. Math can provide
models, but does not necessarily tie models to reality.
My phychology viewpoint comes about because first, nobody can produce
decent objective evidence that their paradigm is better; and second,
those who argue in favor of OOP often suggest that OO better models the
human mind (theirs, not mine).
>
> > It is the implied assumption that OO is objectively better and thus
> > should be *forced* on developers that sets me off. I don't want your
> > personal preferences shoved down my throat, yet this is what the
> > industry is doing. Java removing formal functions is an example of this
> > one-paradigm-fits-all thinking. Gosling should be publicly spanked for
> > that.
>
> Well, programming style is the most important issue for any software firm.
> There is nothing worse than bad standard, except that no standard.
Perhaps even worse is no way to measure whether a standard is any good
such that it turns into a bicker-fest with resentment.
>
> ... and do you want to abolish Java? Count me in!
>
I'll bring enough pitchforks for everybody :-)
Alfredo Novoa
> You seem to have made quite a few assumptions about Object
>Orientation - a few of which are pretty incorrect. This is leading
>me to think that you havnt actually been practicing OO in the real
>world, but have perhaps formed some opinions based on information
>read.
See, I have returned from where you are a long time ago. I know OO
since the late 80's, and I have learnt something about the OO flaws
since then.
>>It was a mistake on my side to use the term "object". I was assuming
>>that object meant "value" and not type. If you meant type then your
>>statement is even more meaningless.
>Anyone with OO experience of any kind would not have made that
>mistake.
Say that to S Perryman and apply the same to you. You said that an
object has operations and only types have operations. In the OO world
the word object is a wildcard for anything, although the most common
meanings are value and variable. Value and variable are two underpining
concepts in imperative programming, and to confuse them leads to the
terrible mistakes we see everyday in the OO world.
>Most OO people should know what 'Type' actually is.
And they should know what a variable is and what a value is but they
call object to both.
It is not surprising that they call object to a type or an operator.
Everything is an object.
>>The identity of a value is nothing but the value itself. The state of a variable is the value
>>it contains.
>Again, failure to grasp the basics. The identity is otherwise in OO
>parlence known as Type.
What a nonsense!
OO calls identity to the address of a a variable. Two variables have
different identities if they have different addresses. This a clumsy
use of the term, and of course what I said is rigorously true. The
identity of a value is nothing but the value itself. This shows some of
the perils of the value/variable confusion.
> State refers to the values of all the
>attributes at a given point of time.
Exactly what I said.
>>A relational database contains all the rules (behavior) of the data in
>>form of integrity constraints, structure and derivation rules.
>Rule and Behaviour are two entirely different things in OO.
Rules dictate behavior everywhere.
> Generally
>in OO a rule is implied by its invariant - the action/behaviour is
>the actual code that implements that rule.
More nonsense. If you want to know what behavior is then read a
dictionary. Behavior is not code, behavior is the manner in which
system operates. Code is a way to implement behavior but not the only
one.
> I've never seen code
>stored in a tuple in a relational database
I have seen that many times.
> - stored procedures yes,
>but the closest that represents in OO is called a class method - these
>are static method in a service class - certainly not OO, but
>procedural in nature.
You don't know what a relational database is. Nothing prohibites
polymorphic operators in the Relational Model. The Third Manifesto
describes a model of inheritance for relational databases.
> The term 'behaviour' in OO refers to the set
>of functionality implemented by the objects methods (code functions) -
In other words: behavior refers to the set of rules the system
enforces. A clear contradiction with your previous words.
RDBMS also implement functionality, but they have richer mechanisms to
implement it. Code functions are only one option, the most primitive
one.
Regards
Alfredo
topmind
Alfredo Novoa wrote:
> AndyW wrote:
>
> > You seem to have made quite a few assumptions about Object
> >Orientation - a few of which are pretty incorrect. This is leading
> >me to think that you havnt actually been practicing OO in the real
> >world, but have perhaps formed some opinions based on information
> >read.
>
> See, I have returned from where you are a long time ago. I know OO
> since the late 80's, and I have learnt something about the OO flaws
> since then.
>
> >>It was a mistake on my side to use the term "object". I was assuming
> >>that object meant "value" and not type. If you meant type then your
> >>statement is even more meaningless.
>
> >Anyone with OO experience of any kind would not have made that
> >mistake.
Guys guys, there has yet to be any consensus definition of OOP created.
Debates over what OOP really is go on for months. Thus, arguing that
you know the "real" definition and the other person doesn't is probably
pointless. Further, different shops have different techniques and rules
for OO design.
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 13 May 2006 16:26:58 -0700, topmind wrote:
>>
>> Others, like C.J. Date, have understood the
>> role of types, identity, generic programming. They are welcome. [ I cannot
>> tell if they represent majority and whether majority really understands and
>> accepts all consequences of bringing types to RM. It does not look so,
>> after debates RM guys. ]
>
> I generally consider relational to be orthogonal to "types".
No. To be orthogonal it requires at least dropping x->{x} axiom of set
theory, which exactly what flawed SQL does.
>>>> Because, IMO, it is quite obvious that technically RM is nothing
>>>> but specialized containers.
>>>
>>> This sounds like the old "OO is better because OO is a superset of RM".
>>> I generally *agree* with this in part. RM imposes rules that OO does
>>> not. These rules provide consistency in design, and OO's lack of
>>> consistency is one of my biggest complaints about it.
>>
>> Nobody wants to intentionally propose an inconsistent framework. So to make
>> a point you should show that RM may not have consistent supersets. [ For
>> example in mathematics, reals extend integers, complex extend reals, but
>> the field of complex numbers cannot be extended anymore. ]
>
> I am not sure what you mean. Why would I have to show that RM does not
> have consistent supersets when that is not what I claimed?
If RM can have a consistent superset, then OO could be one. Any lack of
consistency it might have, can be fixed.
>>>> One cannot close this discussion forever,
>>>> because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
>>>> give up their home-brewed philosophies and calmly discuss things in formal
>>>> (=language) terms. [ 2) implies 1) and 1) does 2) ]
>>>
>>> I have concluded that this is largely because software engineering is
>>> mostly about *psychology* and not math nor science.
>>
>> That's new to me. Though, the argumentation style of some RM guys (all
>> these "bullshit", "horseshit" etc) leaves some space to suspicions.
>
> Some RM fans talk about the mathematical background of RM. Following
> math alone is no guarentee of utility, however. Math can provide
> models, but does not necessarily tie models to reality.
Mathematics provides consistency and rigor. It is important to make sure
that people are talking about same things.
S Perryman
> Steven Perryman wrote:
SP>An object can also be considered as an instance of a tuple (where the
SP>tuple defines the properties of the type) .
AN>This is a monumental mistake, objects are a subset of your a/b/c
AN>values. Objects are encapsulated (scalar values) while tuples have
AN>visible components. For instance a tuple of grade 2 is known as a pair,
AN>a tuple of grade 3 is known as a triplet, etc.
>>An object definition (ie type) is a collection of properties.
> It was a mistake on my side to use the term "object". I was assuming
> that object meant "value" and not type. If you meant type then your
> statement is even more meaningless.
More "meaningless" ??
As "meaningless" as a previous comment was "absurd" ??
So absurd that you had to repost to acknowledge the comment (but notably
without apologising for claiming the content was absurd - the pattern is
duly noted - time will tell whether you are true to type) .
Lovely debating style you have.
> So object sometimes means value, sometimes means variable and sometimes
> means type. We only need to call object to operations to completely
> mess the key concepts of imperative programming.
>>That definition can be easily represented in tuple form.
>>As can object instances.
> You are mixing apples with oranges.
Not at all.
>>There is no conceptual difference between :
>>Person = (name: string, age: int)
>>and
>>type Person { name: string, age: int }
> If the first Person is a scalar type and the second Person is a tuple
> type there is a conceptual difference.
> BTW I don't know any relational language which allows to define tuple
> types. Date and Darwen deprecated that feature.
> Person(name 'Juan', age 20)
> is a singleton
> tuple { name 'Juan', age 20 }
> is a pair.
> Notice that "Person" dissapeared in the tuple.
Don't be pedantic.
All "Person" is in the real world, is a label for a definition that
describes
a set of tuples of which "(name 'Juan', age 20)" is an instance.
>>An element of a tuple can be an operation (probably bound to a free
>>variable - the tuple itself perhaps) .
> If you do that what you have is a tuple function. Tuple is the short
> for tuple value and values are immutable.
> But the question is that there is not any difference between the RM and
> OO in this.
Indeed. And it should be ringing alarm bells for you.
Specifically that your "RM" is not some "superset" of OO, but there is a
mathematical foundation that can quite easily allow both models to exist
interchangeably. A foundation IMHO that the RM does not have sole rights to.
>>Whether y refers to an actual value, or an operation that computes the
>>value, is irrelevant. In Functional Programming, this is called
>>"referential
>>transparency" .
> Referential transparency is also important in the RM. We discussed the
> topic extensively in TTM mail list.
More alarm bells ringing.
Regards,
Steven Perryman
AndyW
wrote:
Yes :)
But making up ones own definition to prove a point is probably not a
good idea. At least if not quoting a 'name' - a standard reference to
where the information came from.
I've simply used of the main definitons from booch (1991) p.77 -
Identity state and action (behaviour). A well formed notion from one
of the formative OO texts.
Alfredo Novoa
>More "meaningless" ??
Indeed.
>As "meaningless" as a previous comment was "absurd" ??
No, previous comment was "monumental mistake". The "absurd" statement
was another.
>So absurd that you had to repost to acknowledge the comment (but notably
>without apologising for claiming the content was absurd - the pattern is
>duly noted - time will tell whether you are true to type) .
I mantain that is was absurd, I reposted to comment another thing.
>> Person(name 'Juan', age 20)
>> is a singleton
>> tuple { name 'Juan', age 20 }
>> is a pair.
>> Notice that "Person" dissapeared in the tuple.
>Don't be pedantic.
>All "Person" is in the real world, is a label for a definition that
>describes
>a set of tuples of which "(name 'Juan', age 20)" is an instance.
I was not pedantic, I was trying to explain something you completely
fail to understand.
Although this is not completely your fault because OO terminology is
terribly confusing.
Person(string name, int age)
is the signature of an operator that returns a single scalar VALUE.
type Person relation { Name Char, Age Integer }
is a relation TYPE definition. And I don't know any language which
allows this.
new Person('Juan', 20)
is equivalent to
tuple { new Person('Juan', 20) }
And of course we could do:
var R relation { P Person } key { P };
R := relation { tuple { P new Person('Juan', 20) } };
>>>An element of a tuple can be an operation (probably bound to a free
>>>variable - the tuple itself perhaps) .
>> If you do that what you have is a tuple function. Tuple is the short
>> for tuple value and values are immutable.
>> But the question is that there is not any difference between the RM and
>> OO in this.
>Indeed. And it should be ringing alarm bells for you.
>Specifically that your "RM" is not some "superset" of OO
The RM and OO are orthogonal. I never said that The RM is a superset of
OO.
>, but there is a
>mathematical foundation that can quite easily allow both models to exist
>interchangeably.
What a non sequitur! From a function in a tuple you inferred all this!
On the other hand OO is not a model in the same sense as the RM. OO is
a fuzzy an unconsensed set of coding techniques and guidelines. The RM
is a formal data management model.
Regards
Alfredo
topmind
> On 14 May 2006 11:05:58 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 13 May 2006 16:26:58 -0700, topmind wrote:
> >>
> >> Others, like C.J. Date, have understood the
> >> role of types, identity, generic programming. They are welcome. [ I cannot
> >> tell if they represent majority and whether majority really understands and
> >> accepts all consequences of bringing types to RM. It does not look so,
> >> after debates RM guys. ]
> >
> > I generally consider relational to be orthogonal to "types".
>
> No. To be orthogonal it requires at least dropping x->{x} axiom of set
> theory, which exactly what flawed SQL does.
I am not sure what set operator "->" represents. I don't recognize it.
Anyhow, here is an example of what I meant by orthogonal to types.
Let's take a sample SQL statement:
SELECT *
FROM foo
WHERE columnA + columnB > columnC
Let's use a functional syntax to represent the same thing:
SELECT *
FROM foo
WHERE greaterThan(add(columnA,columnB),columnC)
Now every typical expression can be represented with nothing but column
references, operations (functions) on columns, and/or other such
operations. For good measure we should probably throw in constants
also. The usual infix notation (like "A + B") we are familiar with is
just syntactical sugar to help our eyes.
Conceptually, relational expressions should not care what these
operators are as long as the final expression returns something that
can be interpreted as a Boolean value in order to filter rows. We
assume regular Euclidian math and Boolean algebra because that is what
we are familiar with. However, I see nothing in relational algebra that
excludes the idea of "custom maths" or custom types for specific
domains or uses.
Somebody could make up a weird math with odd operators (using our
functional syntax for familarity):
SELECT *
FROM foo
WHERE zlog(drek(columnA,columnB),fleek(columnC))
As long as "zlog" returns something that can be interpreted as a
Boolean expression, it can be part of relational math. The "expression
engine" is generally separate from the relational engine and/or
relational math. Relational math operations generally fit the form of:
table = relationalOperator(table, expression, ...[more tables or
expressions]..)
The relational operators are "fixed" (at least the base ones), but the
expressions are open-ended as long as they fit the criteria already
described. Relational imposes rules at the table level, but not at the
cell level. Cell-level operations can do/use whatever math model they
want as long as they recognize columns in some way. They are only
constrained when they are "fed" to relational math. In other words, the
intersection between the "table math" (relational) and the domain or
custom math (expression system) can be kept fairly small to give the
expression math a lot of room.
Another way to say this is that relational math and the domain/custom
math can be treated as orthogonal worlds and only have to agree on a
minimal set of protocols to talk to each other. All the domain math
needs is adaptor operators that can convert domain math results into
Boolean so that the relational world can act on it, and a way to ask
the relational engine for column content. Other than being a "keeper",
the relational engine does not care what is in the column cell.
In the example above, "zlog" is such an adaptor. The "fleek" operator
(toward the right of example) may or may not be usable to the
relational engine. We don't know without looking at its type or domain
indicator.
(Aggregation may require yet more rules. I'll have to ponder this one.)
>
> >>>> Because, IMO, it is quite obvious that technically RM is nothing
> >>>> but specialized containers.
> >>>
> >>> This sounds like the old "OO is better because OO is a superset of RM".
> >>> I generally *agree* with this in part. RM imposes rules that OO does
> >>> not. These rules provide consistency in design, and OO's lack of
> >>> consistency is one of my biggest complaints about it.
> >>
> >> Nobody wants to intentionally propose an inconsistent framework. So to make
> >> a point you should show that RM may not have consistent supersets. [ For
> >> example in mathematics, reals extend integers, complex extend reals, but
> >> the field of complex numbers cannot be extended anymore. ]
> >
> > I am not sure what you mean. Why would I have to show that RM does not
> > have consistent supersets when that is not what I claimed?
>
> If RM can have a consistent superset, then OO could be one. Any lack of
> consistency it might have, can be fixed.
But a super-set is not automatically a good thing. Something too
open-ended could lack enough constraints to provide some form of
consistency. I would like to see an example.
>
> >>>> One cannot close this discussion forever,
> >>>> because: 1) OO lacks necessary formalism, 2) people on both sides refuse to
> >>>> give up their home-brewed philosophies and calmly discuss things in formal
> >>>> (=language) terms. [ 2) implies 1) and 1) does 2) ]
> >>>
> >>> I have concluded that this is largely because software engineering is
> >>> mostly about *psychology* and not math nor science.
> >>
> >> That's new to me. Though, the argumentation style of some RM guys (all
> >> these "bullshit", "horseshit" etc) leaves some space to suspicions.
> >
> > Some RM fans talk about the mathematical background of RM. Following
> > math alone is no guarentee of utility, however. Math can provide
> > models, but does not necessarily tie models to reality.
>
> Mathematics provides consistency and rigor. It is important to make sure
> that people are talking about same things.
All else being equal, I generally agree. A math-influenced base is
usually a good thing to have, but is no guarentee of a useful notation
by itself.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 14 May 2006 11:05:58 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On 13 May 2006 16:26:58 -0700, topmind wrote:
>>>>
>>>> Others, like C.J. Date, have understood the
>>>> role of types, identity, generic programming. They are welcome. [ I cannot
>>>> tell if they represent majority and whether majority really understands and
>>>> accepts all consequences of bringing types to RM. It does not look so,
>>>> after debates RM guys. ]
>>>
>>> I generally consider relational to be orthogonal to "types".
>>
>> No. To be orthogonal it requires at least dropping x->{x} axiom of set
>> theory, which exactly what flawed SQL does.
>
> I am not sure what set operator "->" represents. I don't recognize it.
It means that a set can be a member of another set.
> Anyhow, here is an example of what I meant by orthogonal to types.
> Let's take a sample SQL statement:
>
> SELECT *
> FROM foo
> WHERE columnA + columnB > columnC
If I want to insert the table "foo" in the table "bar", what kind of CREATE
I need for "bar"?
[...]
There is no orthogonality between types and RM, and cannot be. You can
pretend that there is one no longer a very weak language is considered,
like SQL.
>> If RM can have a consistent superset, then OO could be one. Any lack of
>> consistency it might have, can be fixed.
>
> But a super-set is not automatically a good thing. Something too
> open-ended could lack enough constraints to provide some form of
> consistency. I would like to see an example.
No, running in circles does not support your wrong point. As I said before,
to make it you have to show that any extension of RM is necessarily
inconsistent.
Bart Wakker
> This sounds like the old "OO is better because OO is a superset of
> RM". I generally *agree* with this in part. RM imposes rules that
> OO does not. These rules provide consistency in design, and OO's
Depends. The RM constraints are fine and necessary, but without
triggers and some embedded language quite limited. OO also has
constraints if you want, just add them to your classes as you like
e.g. as pre-condition in your constructor. The referential integrity
is a given in OO, you don't think about it but it is the base of your
own model. Of course it lacks decent data retrieval, but apart from
that you could envisage a 'database' of serialized instances alone
(apart from sever practical problems).
> lack of consistency is one of my biggest complaints about it. OO
> designs are the modern-day GOTO's: navigational speghetti similar to
> what motivated Dr. Codd to fix it.
That is a point of view. It makes some people nervous when they don't
recognize a flow of control, however the same can be said from logical
languages such a prolog. You must use some guidelines however, design
a proper layering and forbid circular references except for small and
well understood cases.
>
> It is the implied assumption that OO is objectively better and thus
> should be *forced* on developers that sets me off. I don't want your
> personal preferences shoved down my throat, yet this is what the
> industry is doing. Java removing formal functions is an example of
> this one-paradigm-fits-all thinking. Gosling should be publicly
> spanked for that.
>
Use the right tool for the job. For reporting purposes it is insane to
use OO, for simulations OO often is very fit (OO started out as
simula 67) as well as for GUI frameworks.
However in a 50-100 developer project, it is not so practical that
each developer chooses his own method or architecture :). More it is
that the project chooses the developers that fit to the chosen
methodology.
Gosling tried to make a simple language that can be understood by
average programmers. I think it is just because he feels that java is
not the only possible tool that he decided to restrict it. In
contrast, .NET tries to incorporate every paradigm in the world and
thus "embrace and extend" everything, you should never have to move
outside of the .net world. Java has limited use and scope, but is
decent for what it is meant for. I don't miss functions in java, when
I need them I use lisp or scheme.
topmind
Why does Booch get to define it? Why not Nygaard (sp?), Alan Kay,
Bertrand Meyer, or my Uncle Bob?
-T-
topmind
> "topmind" <top...@technologist.com> writes:
>
> > This sounds like the old "OO is better because OO is a superset of
> > RM". I generally *agree* with this in part. RM imposes rules that
> > OO does not. These rules provide consistency in design, and OO's
>
> Depends. The RM constraints are fine and necessary, but without
> triggers and some embedded language quite limited.
It is not the intent of RM to do everything. It is called
specialization. Let RM do what it does well and app code do what it
does well. Yin and Yang. (Related are the Prolog statements below.)
> OO also has
> constraints if you want, just add them to your classes as you like
> e.g. as pre-condition in your constructor.
Yes it can be done, but note that it only works in one app or one
language. DB contraints apply to ANY app or tool that accesses the
data. OOP tends to be linguistically xenophobic in that regard.
> The referential integrity
> is a given in OO, you don't think about it but it is the base of your
> own model.
Not all practial constraints may belong in the base classes.
> Of course it lacks decent data retrieval, but apart from
> that you could envisage a 'database' of serialized instances alone
> (apart from sever practical problems).
But that gives you the navigational messes more or less that Codd set
out to escape from in the late 60's.
>
> > lack of consistency is one of my biggest complaints about it. OO
> > designs are the modern-day GOTO's: navigational speghetti similar to
> > what motivated Dr. Codd to fix it.
>
> That is a point of view. It makes some people nervous when they don't
> recognize a flow of control, however the same can be said from logical
> languages such a prolog. You must use some guidelines however, design
> a proper layering and forbid circular references except for small and
> well understood cases.
Prolog tries to do the whole thing with one technique/paradigm. RM
allows a kind of partitioning of data issues and app-specific issues
where they are best suited.
>
> >
> > It is the implied assumption that OO is objectively better and thus
> > should be *forced* on developers that sets me off. I don't want your
> > personal preferences shoved down my throat, yet this is what the
> > industry is doing. Java removing formal functions is an example of
> > this one-paradigm-fits-all thinking. Gosling should be publicly
> > spanked for that.
> >
>
> Use the right tool for the job. For reporting purposes it is insane to
> use OO, for simulations OO often is very fit (OO started out as
> simula 67) as well as for GUI frameworks.
Physical simulations are generally outside of my professional
experience, so I won't question it there. However, for GUI's,
mostly-declarative frameworks are the way to go IMO. OO Set/get's of
GUI attributes are verbose and cluttery. Declarative frameworks are
also easier to make multi-language. I see no reason to have to reinvent
the GUI for each and every language.
>
> However in a 50-100 developer project, it is not so practical that
> each developer chooses his own method or architecture :). More it is
> that the project chooses the developers that fit to the chosen
> methodology.
Perhaps. But how does that make OO better?
>
> Gosling tried to make a simple language that can be understood by
> average programmers. I think it is just because he feels that java is
> not the only possible tool that he decided to restrict it. In
> contrast, .NET tries to incorporate every paradigm in the world and
> thus "embrace and extend" everything, you should never have to move
> outside of the .net world. Java has limited use and scope, but is
> decent for what it is meant for. I don't miss functions in java, when
> I need them I use lisp or scheme.
In the same app you are mixing languages *just* to get functions? I
like functions, but mixing languages because Java lacks them is a bit
extreme.
-T-
topmind
Dmitry A. Kazakov wrote:
> On 15 May 2006 17:13:33 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 14 May 2006 11:05:58 -0700, topmind wrote:
> >>
> >>> Dmitry A. Kazakov wrote:
> >>>> On 13 May 2006 16:26:58 -0700, topmind wrote:
> >>>>
> >>>> Others, like C.J. Date, have understood the
> >>>> role of types, identity, generic programming. They are welcome. [ I cannot
> >>>> tell if they represent majority and whether majority really understands and
> >>>> accepts all consequences of bringing types to RM. It does not look so,
> >>>> after debates RM guys. ]
> >>>
> >>> I generally consider relational to be orthogonal to "types".
> >>
> >> No. To be orthogonal it requires at least dropping x->{x} axiom of set
> >> theory, which exactly what flawed SQL does.
> >
> > I am not sure what set operator "->" represents. I don't recognize it.
>
> It means that a set can be a member of another set.
I see no reason to include nested sets in RM. RM is based on set
theory, not trees (nestedness). If SQL violates such, then it indeed
may be flawed in that regard. Very few RM fans consider SQL the
pinnacle of relational language possibilities.
>
> > Anyhow, here is an example of what I meant by orthogonal to types.
> > Let's take a sample SQL statement:
> >
> > SELECT *
> > FROM foo
> > WHERE columnA + columnB > columnC
>
> If I want to insert the table "foo" in the table "bar", what kind of CREATE
> I need for "bar"?
See above
>
> [...]
>
> There is no orthogonality between types and RM, and cannot be. You can
> pretend that there is one no longer a very weak language is considered,
> like SQL.
Please clarify.
AndyW
wrote:
No real reason, most started working with the idea around the same
time - just that Booch's book was used more as a reference. Just like
the GOF patterns book is today. There were others who published of
course, remember Rumbaugh and co. Banning fuzzy clouds was a good
idea at the end of the day :)
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 15 May 2006 17:13:33 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>> It means that a set can be a member of another set.
>
> I see no reason to include nested sets in RM.
Farewell, set theory...
>> There is no orthogonality between types and RM, and cannot be. You can
>> pretend that there is one no longer a very weak language is considered,
>> like SQL.
>
> Please clarify.
Like one that does not have sets of sets.
topmind
Dmitry A. Kazakov wrote:
> On 18 May 2006 21:47:52 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 15 May 2006 17:13:33 -0700, topmind wrote:
> >>
> >>> Dmitry A. Kazakov wrote:
>
> >> It means that a set can be a member of another set.
> >
> > I see no reason to include nested sets in RM.
>
> Farewell, set theory...
What is a practical example of their utility?
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 18 May 2006 21:47:52 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On 15 May 2006 17:13:33 -0700, topmind wrote:
>>>>
>>>>> Dmitry A. Kazakov wrote:
>>
>>>> It means that a set can be a member of another set.
>>>
>>> I see no reason to include nested sets in RM.
>>
>> Farewell, set theory...
>
> What is a practical example of their utility?
Utility of what? Of set theory?
Ever watched TV? Sometimes the moderator asks you to send a mail and put in
an envelope with your address on it. So that they could send you a brochure
or something else back. An ability to put one envelope into another
demonstrates utility of nested sets.
BTW, care to show a practical example of RM? I mean something more
substantial than just selling 50kbucks RDBMS's nobody except IT managers
needs... (:-))
topmind
Dmitry A. Kazakov wrote:
> On 21 May 2006 20:25:05 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 18 May 2006 21:47:52 -0700, topmind wrote:
> >>
> >>> Dmitry A. Kazakov wrote:
> >>>> On 15 May 2006 17:13:33 -0700, topmind wrote:
> >>>>
> >>>>> Dmitry A. Kazakov wrote:
> >>
> >>>> It means that a set can be a member of another set.
> >>>
> >>> I see no reason to include nested sets in RM.
> >>
> >> Farewell, set theory...
> >
> > What is a practical example of their utility?
>
> Utility of what? Of set theory?
No, of *nested* sets.
>
> Ever watched TV? Sometimes the moderator asks you to send a mail and put in
> an envelope with your address on it. So that they could send you a brochure
> or something else back. An ability to put one envelope into another
> demonstrates utility of nested sets.
But in relational modeling one does not put envelope 1 inside of
envelope 2, but would merely reference the "parent envelope"
(parent_ID). Nesting makes it tough to query. Relational tends to
consider such a relationship a specific viewpoint. In OO terms, we
would say "HAS-A" instead of "IS-A". Nesting takes us back to all the
HAS-A problems that OO has: hard-wiring viewpoints and perspectives
that are a pain to undo when change happens. Relational should treat
views and perspectives and relationships as attributes more or less.
You get more flexibility and consistency that way.
Aside from being harder to query, imagine what happens when we take the
envelope out. Using hard-nesting there would be a lot of work,
including updating references to what used to be nested. But using
proper relational we simply remove (or null-out) the Parent_ID
attribute. No existing references to the previously-nested envelope
need be changed.
Nestedness like this is an example where modeling the real world too
closely has nasty side-effects.
>
> BTW, care to show a practical example of RM? I mean something more
> substantial than just selling 50kbucks RDBMS's nobody except IT managers
> needs... (:-))
50K?
Use open-source such as PostGresql, MySql, or SqlLite. There is more to
RDBMS than Oracle. (I used to use a lot of XBase dialects, where
tablizing was nimble and easy. Of course it had scalability problems,
but integration with big-iron RDBMS was later possible and local tables
simply became local views instead. I miss the data-centric days before
OO hype killed lots of good ideas, taking us back to code-centricity
and the navigational 60's.)
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 21 May 2006 20:25:05 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On 18 May 2006 21:47:52 -0700, topmind wrote:
>>>>
>>>>> Dmitry A. Kazakov wrote:
>>>>>> On 15 May 2006 17:13:33 -0700, topmind wrote:
>>>>>>
>>>>>>> Dmitry A. Kazakov wrote:
>>>>
>>>>>> It means that a set can be a member of another set.
>>>>>
>>>>> I see no reason to include nested sets in RM.
>>>>
>>>> Farewell, set theory...
>>>
>>> What is a practical example of their utility?
>>
>> Utility of what? Of set theory?
>
> No, of *nested* sets.
Come on, I carry my purse in a pocket, and you?
>> Ever watched TV? Sometimes the moderator asks you to send a mail and put in
>> an envelope with your address on it. So that they could send you a brochure
>> or something else back. An ability to put one envelope into another
>> demonstrates utility of nested sets.
>
> But in relational modeling one does not put envelope 1 inside of
> envelope 2, but would merely reference the "parent envelope"
> (parent_ID).
Which essentially means that you are going to send a description where TV
guys could find the envelope by you at home. They won't come! They are
*there*, they don't want an ID, they want an *envelope*!
> Nesting makes it tough to query. Relational tends to
> consider such a relationship a specific viewpoint. In OO terms, we
> would say "HAS-A" instead of "IS-A".
No, there is no way. You have to construct the power set to get HAS-A
working. You cannot do that in "unityped" RM.
HAS-A is a relation between a set and its members. IS-A, in the context you
are using it, is a relation between sets. Set theory is quite clear in
treating both separate. This is why power set is an axiom there.
topmind
How does this translate to a problem from technical (developer/modeler)
standpoint? Using physical analogies is not sufficient for
communicating this, I am afraid. Software maps/models of the world are
(fortunately) not constrained the way physical entities are.
>
> > Nesting makes it tough to query. Relational tends to
> > consider such a relationship a specific viewpoint. In OO terms, we
> > would say "HAS-A" instead of "IS-A".
>
> No, there is no way. You have to construct the power set to get HAS-A
> working. You cannot do that in "unityped" RM.
"Parent_ID" is simple yet powerful.
>
> HAS-A is a relation between a set and its members.
I generally disagree with that interpretation. Then again, there are
multiple ways to represent the same thing. In relational thinking you
can reference a set in a member, which is almost like containment
except that it is a reference and not a "hard" nesting. But being a
reference is what makes it powerful and sharable. Hard-nesting carries
a boatload of problems with it.
> Dmitry A. Kazakov
-T-
Dmitry A. Kazakov
>> Come on, I carry my purse in a pocket, and you?
>>
>>>> Ever watched TV? Sometimes the moderator asks you to send a mail and put in
>>>> an envelope with your address on it. So that they could send you a brochure
>>>> or something else back. An ability to put one envelope into another
>>>> demonstrates utility of nested sets.
>>>
>>> But in relational modeling one does not put envelope 1 inside of
>>> envelope 2, but would merely reference the "parent envelope"
>>> (parent_ID).
>>
>> Which essentially means that you are going to send a description where TV
>> guys could find the envelope by you at home. They won't come! They are
>> *there*, they don't want an ID, they want an *envelope*!
>
> How does this translate to a problem from technical (developer/modeler)
> standpoint?
Very directly. TV guys aren't your cohabitants, they don't need to know
anything about where you keep your envelopes. (Otherwise, the very notion
of sending would be rubbish.) They need only an envelope. In software
design it is known as problem decomposition and information hiding
principle. These concepts are of huge importance for *complex* software
systems.
>>> Nesting makes it tough to query. Relational tends to
>>> consider such a relationship a specific viewpoint. In OO terms, we
>>> would say "HAS-A" instead of "IS-A".
>>
>> No, there is no way. You have to construct the power set to get HAS-A
>> working. You cannot do that in "unityped" RM.
>
> "Parent_ID" is simple yet powerful.
Show how Parent_ID could represent power set. Alternatively show me how you
can enumerate subsets of a given set using Parent_ID or in any other way.
>> HAS-A is a relation between a set and its members.
>
> I generally disagree with that interpretation.
So you disagree with set theory, on which RM is based...
> Then again, there are multiple ways to represent the same thing.
No, all these ways are equivalent. In mathematics if you can represent a
thing, then you have it.
> In relational thinking you
> can reference a set in a member, which is almost like containment
> except that it is a reference and not a "hard" nesting.
No. Both are same. If you can reference *any* set (except self and its
subsets) in *any* member, then you *have* nested sets. The problem is that
you cannot.
P.S. The above is not a fundamental weakness of RM, it is a consequence of
"uni-typed" approach. Should RM be properly typed, power sets would
represent no problem, see Date.
topmind
> On 22 May 2006 16:58:30 -0700, topmind wrote:
>
> >> Come on, I carry my purse in a pocket, and you?
> >>
> >>>> Ever watched TV? Sometimes the moderator asks you to send a mail and put in
> >>>> an envelope with your address on it. So that they could send you a brochure
> >>>> or something else back. An ability to put one envelope into another
> >>>> demonstrates utility of nested sets.
> >>>
> >>> But in relational modeling one does not put envelope 1 inside of
> >>> envelope 2, but would merely reference the "parent envelope"
> >>> (parent_ID).
> >>
> >> Which essentially means that you are going to send a description where TV
> >> guys could find the envelope by you at home. They won't come! They are
> >> *there*, they don't want an ID, they want an *envelope*!
> >
> > How does this translate to a problem from technical (developer/modeler)
> > standpoint?
>
> Very directly. TV guys aren't your cohabitants, they don't need to know
> anything about where you keep your envelopes. (Otherwise, the very notion
> of sending would be rubbish.) They need only an envelope. In software
> design it is known as problem decomposition and information hiding
> principle. These concepts are of huge importance for *complex* software
> systems.
I disagree. What complex systems often need is *relativism*. There is
rarely One Right View for everything. Department A may care that X is
nested in Y, but department B may not. For example, a Ford cost
accountant may be concerned about car parts as much as an engineer.
However, the accountant often does not care about the proximity or
nestedness of car parts to one another. If part X is hard-nested under
part Y, then it is more difficult for the accountant to get at Y in
reports, queries, etc. Dr. Codd noticed this in the mid 60's using
hierarchical and network databases and set out to remedy it.
>
> >>> Nesting makes it tough to query. Relational tends to
> >>> consider such a relationship a specific viewpoint. In OO terms, we
> >>> would say "HAS-A" instead of "IS-A".
> >>
> >> No, there is no way. You have to construct the power set to get HAS-A
> >> working. You cannot do that in "unityped" RM.
> >
> > "Parent_ID" is simple yet powerful.
>
> Show how Parent_ID could represent power set. Alternatively show me how you
> can enumerate subsets of a given set using Parent_ID or in any other way.
I don't see the connection between hierarchies and power sets here. It
is apples and oranges. If column_X is not needed for perform a given
task, then simply don't use it.
>
> > Then again, there are multiple ways to represent the same thing.
>
> No, all these ways are equivalent. In mathematics if you can represent a
> thing, then you have it.
>
> > In relational thinking you
> > can reference a set in a member, which is almost like containment
> > except that it is a reference and not a "hard" nesting.
>
> No. Both are same. If you can reference *any* set (except self and its
> subsets) in *any* member, then you *have* nested sets. The problem is that
> you cannot.
Define "have". It is possible to represent nested sets IF such is
needed. I am just against hard-nesting.
>
> P.S. The above is not a fundamental weakness of RM, it is a consequence of
> "uni-typed" approach. Should RM be properly typed, power sets would
> represent no problem, see Date.
Again, I ask to see a practical use-case. "I don't like the way it
represents envelopes" is not very comparative or dissectable. For
example, show how it might waste programmer or query-writer or user
time.
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 22 May 2006 16:58:30 -0700, topmind wrote:
>>
>>>> Come on, I carry my purse in a pocket, and you?
>>>>
>>>>>> Ever watched TV? Sometimes the moderator asks you to send a mail and put in
>>>>>> an envelope with your address on it. So that they could send you a brochure
>>>>>> or something else back. An ability to put one envelope into another
>>>>>> demonstrates utility of nested sets.
>>>>>
>>>>> But in relational modeling one does not put envelope 1 inside of
>>>>> envelope 2, but would merely reference the "parent envelope"
>>>>> (parent_ID).
>>>>
>>>> Which essentially means that you are going to send a description where TV
>>>> guys could find the envelope by you at home. They won't come! They are
>>>> *there*, they don't want an ID, they want an *envelope*!
>>>
>>> How does this translate to a problem from technical (developer/modeler)
>>> standpoint?
>>
>> Very directly. TV guys aren't your cohabitants, they don't need to know
>> anything about where you keep your envelopes. (Otherwise, the very notion
>> of sending would be rubbish.) They need only an envelope. In software
>> design it is known as problem decomposition and information hiding
>> principle. These concepts are of huge importance for *complex* software
>> systems.
>
> I disagree. What complex systems often need is *relativism*.
That is a subject of distributed systems. They are complex, but not all
complex systems are distributed. Nevertheless, for design of a distributed
system your RM framework is totally insufficient. Just show how OSI layers
could be implemented without nesting. Switching subjects won't help you.
Anyway this by no means devaluates my point. Your RM is unsuitable for
problem space decomposition.
>>>>> Nesting makes it tough to query. Relational tends to
>>>>> consider such a relationship a specific viewpoint. In OO terms, we
>>>>> would say "HAS-A" instead of "IS-A".
>>>>
>>>> No, there is no way. You have to construct the power set to get HAS-A
>>>> working. You cannot do that in "unityped" RM.
>>>
>>> "Parent_ID" is simple yet powerful.
>>
>> Show how Parent_ID could represent power set. Alternatively show me how you
>> can enumerate subsets of a given set using Parent_ID or in any other way.
>
> I don't see the connection between hierarchies and power sets here. It
> is apples and oranges. If column_X is not needed for perform a given
> task, then simply don't use it.
It was a simple question. The answer should be either yes or no. And it is
no, you cannot construct a power set or its equivalent.
>> No. Both are same. If you can reference *any* set (except self and its
>> subsets) in *any* member, then you *have* nested sets. The problem is that
>> you cannot.
>
> Define "have".
It was defined in the sentence you quoted.
> It is possible to represent nested sets IF such is
> needed. I am just against hard-nesting.
So, it is needed. Show me a way to represent them.
>> P.S. The above is not a fundamental weakness of RM, it is a consequence of
>> "uni-typed" approach. Should RM be properly typed, power sets would
>> represent no problem, see Date.
>
> Again, I ask to see a practical use-case. "I don't like the way it
> represents envelopes" is not very comparative or dissectable.
You didn't represent it. Envelope is a relation. To represent it you have
to construct a relation of relations. You cannot in your mindset.
--
Regards,
Dmitry A. Kazakov
topmind
Systems software (OSs, compilers, etc.) and networking software are
outside of my field of expertise. I won't challenge your claim in that
area. What is good for one domain may not be in another. Do you have
any examples in the domain of custom business software?
However, I sometimes suspect that distributed systems are overhyped of
late. I see its use in say retail stores that are relatively
independent from each other. However, something that involves a lot of
cross-cordination, such as airline reservations or global
product/package distribution, makes more sense when one consolidates
the databases and servers in one spot, using a client/server-like
architecture where the client only stores temporary copies or views.
>
> Anyway this by no means devaluates my point. Your RM is unsuitable for
> problem space decomposition.
Show me an example of it getting sick in the domain of custom biz
software. There are many ways to decompose software, and I find that
*hierarchies don't scale* because the real world is rarely a clean
hierarchy, at least in my domain of familiarity. Thus, hierarchies and
nestedness do not reflect reality closely enough to be useful.
>
> >>>>> Nesting makes it tough to query. Relational tends to
> >>>>> consider such a relationship a specific viewpoint. In OO terms, we
> >>>>> would say "HAS-A" instead of "IS-A".
> >>>>
> >>>> No, there is no way. You have to construct the power set to get HAS-A
> >>>> working. You cannot do that in "unityped" RM.
> >>>
> >>> "Parent_ID" is simple yet powerful.
> >>
> >> Show how Parent_ID could represent power set. Alternatively show me how you
> >> can enumerate subsets of a given set using Parent_ID or in any other way.
> >
> > I don't see the connection between hierarchies and power sets here. It
> > is apples and oranges. If column_X is not needed for perform a given
> > task, then simply don't use it.
>
> It was a simple question. The answer should be either yes or no.
No, it is a "show me how...." question. I am asking why I need to show
you such. I don't see it relavent to the discussion. In other words,
let's finish Why before focusing on How. Justify your Why question and
then I will answer How if your Why is good.
> And it is
> no, you cannot construct a power set or its equivalent.
>
> >> No. Both are same. If you can reference *any* set (except self and its
> >> subsets) in *any* member, then you *have* nested sets. The problem is that
> >> you cannot.
> >
> > Define "have".
>
> It was defined in the sentence you quoted.
Sorry, I don't see the definition.
>
> > It is possible to represent nested sets IF such is
> > needed. I am just against hard-nesting.
>
> So, it is needed.
This needs justification. I question the common utility.
> Show me a way to represent them.
table: sets
---------------
set_id
set_descript
table: set_members
------------
container_set_ref // f.k. to Sets table
node_type // S=set node, I=item node
member_set_ref // f.k. to Sets table (null if "item" node)
item_ref // f.k. to items (null if "set" node)
I don't know if this is the best way, but it is a possible way. A given
item can be a member of multiple sets and any set can be a member of
multiple sets, brought to you by the power of many-to-many tables.
(Note that the above can also represent recursive nestednesses, for
good or bad.)
>
> >> P.S. The above is not a fundamental weakness of RM, it is a consequence of
> >> "uni-typed" approach. Should RM be properly typed, power sets would
> >> represent no problem, see Date.
> >
> > Again, I ask to see a practical use-case. "I don't like the way it
> > represents envelopes" is not very comparative or dissectable.
>
> You didn't represent it. Envelope is a relation. To represent it you have
> to construct a relation of relations. You cannot in your mindset.
Do you mean in the sense that relation=table? Why would we need a whole
table to represent one envelope? Or nested ones at that?
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 23 May 2006 12:54:39 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On 22 May 2006 16:58:30 -0700, topmind wrote:
>>>>
>> That is a subject of distributed systems. They are complex, but not all
>> complex systems are distributed. Nevertheless, for design of a distributed
>> system your RM framework is totally insufficient. Just show how OSI layers
>> could be implemented without nesting. Switching subjects won't help you.
>
> Systems software (OSs, compilers, etc.) and networking software are
> outside of my field of expertise. I won't challenge your claim in that
> area. What is good for one domain may not be in another. Do you have
> any examples in the domain of custom business software?
I don't think that business application domain represents any distinct
architectural or design problem. For software developing, other
classifications / dichotomies are of importance: distributed, embedded,
real-time, numeric, control, persistent, interactive, intelligent,
redundant, optimization, simulation, translation, mission-critical etc.
> However, I sometimes suspect that distributed systems are overhyped of
> late.
Distributed is the only way of future computing for large systems. We live
in a physical world, you know.
> I see its use in say retail stores that are relatively
> independent from each other. However, something that involves a lot of
> cross-cordination, such as airline reservations or global
> product/package distribution, makes more sense when one consolidates
> the databases and servers in one spot, using a client/server-like
> architecture where the client only stores temporary copies or views.
And how is it different from distributed, with the exception of much
greater risk of failure? The system you are talking about is inherently A)
distributed and B) soft real-time.
>> Anyway this by no means devaluates my point. Your RM is unsuitable for
>> problem space decomposition.
>
> Show me an example of it getting sick in the domain of custom biz
> software.
I don't know what you call "biz-software." So far it looks like anything
one can program in SQL...
>> And it is
>> no, you cannot construct a power set or its equivalent.
>>
>>>> No. Both are same. If you can reference *any* set (except self and its
>>>> subsets) in *any* member, then you *have* nested sets. The problem is that
>>>> you cannot.
>>>
>>> Define "have".
>>
>> It was defined in the sentence you quoted.
>
> Sorry, I don't see the definition.
In mathematics can reference <=> have
>>> It is possible to represent nested sets IF such is
>>> needed. I am just against hard-nesting.
>>
>> So, it is needed.
>
> This needs justification. I question the common utility.
>
>> Show me a way to represent them.
>
> table: sets
> ---------------
> set_id
> set_descript
>
> table: set_members
> ------------
> container_set_ref // f.k. to Sets table
> node_type // S=set node, I=item node
> member_set_ref // f.k. to Sets table (null if "item" node)
> item_ref // f.k. to items (null if "set" node)
This does not represent it operationally. You put all sets into Sets table
and represented member_of relation. It is a trick. Clearly, any relation
can be represented as a relation. But how did you get the subsets into Sets
table? Where is the relation subset_of? How can you compare two subsets?
How can you SELECT a set of subsets from the original table? You have shown
how to SELECT form an *existing* table of subsets *knowing* the subset.
>>>> P.S. The above is not a fundamental weakness of RM, it is a consequence of
>>>> "uni-typed" approach. Should RM be properly typed, power sets would
>>>> represent no problem, see Date.
>>>
>>> Again, I ask to see a practical use-case. "I don't like the way it
>>> represents envelopes" is not very comparative or dissectable.
>>
>> You didn't represent it. Envelope is a relation. To represent it you have
>> to construct a relation of relations. You cannot in your mindset.
>
> Do you mean in the sense that relation=table? Why would we need a whole
> table to represent one envelope? Or nested ones at that?
Purely relationally, envelope is a relation:
Envelope : x -> Boolean // x is either in or not
Set theory requires Envelope and x be of different types. Otherwise, you
get Russell's paradox. In your RM the type of relations [table] is not the
type of x's [integer, string, etc]. So far so good. But an envelope can be
put into another! See the problem? You physically cannot do it in your
system. You need referential types like table_ref among integer, string,
etc first class types, or, equivalently, you need a hierarchy of types:
table_of_tables, table_of_tables_of tables, etc. This is what all modern
type systems do. And this is irrelevant to RM vs. OO controversy.
Actually, it is hundred years old hat. Cantor had started his set theory,
and soon mathematicians began to believe that everything can be reduced to
sets. And indeed numbers can be constructed from sets. That would an
untyped system, you are so desperately striving after. Yes, one can
construct integers, strings, data and all other first-order things out of
sets and so out of relations! *But* quite soon mathematicians discovered
that this naive set theory was infested with paradoxes. Types solved that
(among with other things they are useful for).
So whether you like it or not, but you cannot make RM a paradigm without an
elaborated types system. I saw no RM proponent, except you, who would deny
this trivial fact.
--
Regards,
Dmitry A. Kazakov
topmind
Dmitry A. Kazakov wrote:
> On 24 May 2006 10:15:03 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 23 May 2006 12:54:39 -0700, topmind wrote:
> >>
> >>> Dmitry A. Kazakov wrote:
> >>>> On 22 May 2006 16:58:30 -0700, topmind wrote:
> >>>>
> >> That is a subject of distributed systems. They are complex, but not all
> >> complex systems are distributed. Nevertheless, for design of a distributed
> >> system your RM framework is totally insufficient. Just show how OSI layers
> >> could be implemented without nesting. Switching subjects won't help you.
> >
> > Systems software (OSs, compilers, etc.) and networking software are
> > outside of my field of expertise. I won't challenge your claim in that
> > area. What is good for one domain may not be in another. Do you have
> > any examples in the domain of custom business software?
>
> I don't think that business application domain represents any distinct
> architectural or design problem. For software developing, other
> classifications / dichotomies are of importance: distributed, embedded,
> real-time, numeric, control, persistent, interactive, intelligent,
> redundant, optimization, simulation, translation, mission-critical etc.
>
> > However, I sometimes suspect that distributed systems are overhyped of
> > late.
>
> Distributed is the only way of future computing for large systems. We live
> in a physical world, you know.
Well, I have not seen a good case for distributed so far. If you wish
to present your case, then perhaps start another topic in the relavent
forum.
>
> > I see its use in say retail stores that are relatively
> > independent from each other. However, something that involves a lot of
> > cross-cordination, such as airline reservations or global
> > product/package distribution, makes more sense when one consolidates
> > the databases and servers in one spot, using a client/server-like
> > architecture where the client only stores temporary copies or views.
>
> And how is it different from distributed, with the exception of much
> greater risk of failure? The system you are talking about is inherently A)
> distributed and B) soft real-time.
Please clarify. Locational partitioning splits stuff by one factor
(usually location) at the expense of all the other factors. Most biz's
have roughly about 4 to 20 major factors in them, location being just
one. You make location happy by hampering the other 19 or so factors.
Bandwidth is cheap enough in most cases such that processing
interrelationships is the bottleneck, not transfering I/O.
Interrelationship calculation (such as cross-referencing) is the
largest bottleneck these days, not network bandwidth and not raw
computation cost. If you agree with this, then the logical solution is
centralization of the domain "model"
>
> >> Anyway this by no means devaluates my point. Your RM is unsuitable for
> >> problem space decomposition.
> >
> > Show me an example of it getting sick in the domain of custom biz
> > software.
>
> I don't know what you call "biz-software." So far it looks like anything
> one can program in SQL...
No. It looks like we will have a difficult time coming up with a mutual
example here. How about the airline reservation system mentioned.
>
> >> And it is
> >> no, you cannot construct a power set or its equivalent.
> >>
> >>>> No. Both are same. If you can reference *any* set (except self and its
> >>>> subsets) in *any* member, then you *have* nested sets. The problem is that
> >>>> you cannot.
> >>>
> >>> Define "have".
> >>
> >> It was defined in the sentence you quoted.
> >
> > Sorry, I don't see the definition.
>
> In mathematics can reference <=> have
Referencing is not necessarily nesting.
>
> >>> It is possible to represent nested sets IF such is
> >>> needed. I am just against hard-nesting.
> >>
> >> So, it is needed.
> >
> > This needs justification. I question the common utility.
> >
> >> Show me a way to represent them.
> >
> > table: sets
> > ---------------
> > set_id
> > set_descript
> >
> > table: set_members
> > ------------
> > container_set_ref // f.k. to Sets table
> > node_type // S=set node, I=item node
> > member_set_ref // f.k. to Sets table (null if "item" node)
> > item_ref // f.k. to items (null if "set" node)
>
> This does not represent it operationally. You put all sets into Sets table
> and represented member_of relation. It is a trick. Clearly, any relation
> can be represented as a relation. But how did you get the subsets into Sets
> table? Where is the relation subset_of? How can you compare two subsets?
You are correct, I did not define typical or common set operators here.
But that is an implementation detail to be implemented with stored
procedures or app API's. I am not necessarily proposing that everything
be done thru SQL. (If we were using a more powerful query language,
then perhaps it could be intregrated.)
> How can you SELECT a set of subsets from the original table?
Select member_set_ref
from set_members where container_set_ref = &targetSet&
> You have shown
> how to SELECT form an *existing* table of subsets *knowing* the subset.
>
> >>>> P.S. The above is not a fundamental weakness of RM, it is a consequence of
> >>>> "uni-typed" approach. Should RM be properly typed, power sets would
> >>>> represent no problem, see Date.
> >>>
> >>> Again, I ask to see a practical use-case. "I don't like the way it
> >>> represents envelopes" is not very comparative or dissectable.
> >>
> >> You didn't represent it. Envelope is a relation. To represent it you have
> >> to construct a relation of relations. You cannot in your mindset.
> >
> > Do you mean in the sense that relation=table? Why would we need a whole
> > table to represent one envelope? Or nested ones at that?
>
> Purely relationally, envelope is a relation:
>
> Envelope : x -> Boolean // x is either in or not
>
> Set theory requires Envelope and x be of different types.
Set theory does not address types that I can see.
> Otherwise, you
> get Russell's paradox. In your RM the type of relations [table] is not the
> type of x's [integer, string, etc]. So far so good. But an envelope can be
> put into another! See the problem? You physically cannot do it in your
> system. You need referential types like table_ref among integer, string,
> etc first class types, or, equivalently, you need a hierarchy of types:
> table_of_tables, table_of_tables_of tables, etc.
I already argued that "types" are for the most part orthogonal to RM. I
agree that existing implementations are limited in that regard, but I
would rather have dynamic or type-free DB's anyhow.
> This is what all modern
> type systems do. And this is irrelevant to RM vs. OO controversy.
Well, type-centricity is not necessary to produce software. Some dig
heavy typing, others like me would rather do away with it.
>
> Actually, it is hundred years old hat. Cantor had started his set theory,
> and soon mathematicians began to believe that everything can be reduced to
> sets. And indeed numbers can be constructed from sets. That would an
> untyped system, you are so desperately striving after. Yes, one can
> construct integers, strings, data and all other first-order things out of
> sets and so out of relations! *But* quite soon mathematicians discovered
> that this naive set theory was infested with paradoxes. Types solved that
> (among with other things they are useful for).
I would like to see a practical manifestation of the alleged problems.
Matching math to the real world is always going to be an imperfect
marriage because the real world is messier than math that tries to
model it the vast majority of times.
>
> So whether you like it or not, but you cannot make RM a paradigm without an
> elaborated types system. I saw no RM proponent, except you, who would deny
> this trivial fact.
If it is trivial, then let's see a trivial demonstration. We need to
road-test ideas. Otherwise, the best plans of mice and men....
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>>
>> Distributed is the only way of future computing for large systems. We live
>> in a physical world, you know.
>
> Well, I have not seen a good case for distributed so far. If you wish
> to present your case, then perhaps start another topic in the relavent
> forum.
That does not require any show cases.
>>> I see its use in say retail stores that are relatively
>>> independent from each other. However, something that involves a lot of
>>> cross-cordination, such as airline reservations or global
>>> product/package distribution, makes more sense when one consolidates
>>> the databases and servers in one spot, using a client/server-like
>>> architecture where the client only stores temporary copies or views.
>>
>> And how is it different from distributed, with the exception of much
>> greater risk of failure? The system you are talking about is inherently A)
>> distributed and B) soft real-time.
>
> Please clarify. Locational partitioning splits stuff by one factor
> (usually location) at the expense of all the other factors. Most biz's
> have roughly about 4 to 20 major factors in them, location being just
> one. You make location happy by hampering the other 19 or so factors.
> Bandwidth is cheap enough in most cases such that processing
> interrelationships is the bottleneck, not transfering I/O.
>
> Interrelationship calculation (such as cross-referencing) is the
> largest bottleneck these days, not network bandwidth and not raw
> computation cost. If you agree with this, then the logical solution is
> centralization of the domain "model"
Which is completely irrelevant to A and B. Those are *requirements*. As for
design, no, you won't get that contract, just because of B, which reads:
"quality of service gradually influences the value of." If the system isn't
24-hours available you won't get a penny for it.
> No. It looks like we will have a difficult time coming up with a mutual
> example here. How about the airline reservation system mentioned.
Fine, write a communication protocol in *your* RM.
>>>>>> No. Both are same. If you can reference *any* set (except self and its
>>>>>> subsets) in *any* member, then you *have* nested sets. The problem is that
>>>>>> you cannot.
>>>>>
>>>>> Define "have".
>>>>
>>>> It was defined in the sentence you quoted.
>>>
>>> Sorry, I don't see the definition.
>>
>> In mathematics can reference <=> have
>
> Referencing is not necessarily nesting.
As I said, it does not matter. Reference it, that will be fine.
> You are correct, I did not define typical or common set operators here.
> But that is an implementation detail to be implemented with stored
> procedures or app API's. I am not necessarily proposing that everything
> be done thru SQL. (If we were using a more powerful query language,
> then perhaps it could be intregrated.)
That is exactly the point. Your RM is too weak to be a viable paradigm. A
more powerful language probably could, but *only* if it were properly
typed.
>> Purely relationally, envelope is a relation:
>>
>> Envelope : x -> Boolean // x is either in or not
>>
>> Set theory requires Envelope and x be of different types.
>
> Set theory does not address types that I can see.
Google is your friend.
>> Otherwise, you
>> get Russell's paradox. In your RM the type of relations [table] is not the
>> type of x's [integer, string, etc]. So far so good. But an envelope can be
>> put into another! See the problem? You physically cannot do it in your
>> system. You need referential types like table_ref among integer, string,
>> etc first class types, or, equivalently, you need a hierarchy of types:
>> table_of_tables, table_of_tables_of tables, etc.
>
> I already argued that "types" are for the most part orthogonal to RM.
You clamed it without giving anything in support of the claim. So far I saw
no single argument beyond "show me a case", "no math", "it's not biz."
> I agree that existing implementations are limited in that regard, but I
> would rather have dynamic or type-free DB's anyhow.
That changes nothing. Mathematically the time when you *can* determine the
type is irrelevant.
>> This is what all modern
>> type systems do. And this is irrelevant to RM vs. OO controversy.
>
> Well, type-centricity is not necessary to produce software. Some dig
> heavy typing, others like me would rather do away with it.
Software engineering is for producing software.
> I would like to see a practical manifestation of the alleged problems.
See the librarian paradox as an example.
> Matching math to the real world is always going to be an imperfect
> marriage because the real world is messier than math that tries to
> model it the vast majority of times.
What do you have instead of mathematics? Knitting?
>> So whether you like it or not, but you cannot make RM a paradigm without an
>> elaborated types system. I saw no RM proponent, except you, who would deny
>> this trivial fact.
>
> If it is trivial, then let's see a trivial demonstration.
Just write a program that creates power set of a given set.
topmind
Centralization and reliability are not necessarily at odds. One can
have mirrored drives, realtime DB replication, etc.
As far as seperating locations so that no one terrorist bomb or
hurricane wipes out everything, there is remote mirroring also.
However, it makes sense for one installation to be the "primary" at any
one time because it is tough to keep locations separated by thousands
of miles in synch in real time. For one, it is hard or impossible to
maintain A.C.I.D. and high response if multiple locations are being
used in production.
>
> > No. It looks like we will have a difficult time coming up with a mutual
> > example here. How about the airline reservation system mentioned.
>
> Fine, write a communication protocol in *your* RM.
Again, I won't really defend RM outside my domain of expertise. (It can
probably be done, but I don't have enough experience in comm to do it
quickly here.)
> > You are correct, I did not define typical or common set operators here.
> > But that is an implementation detail to be implemented with stored
> > procedures or app API's. I am not necessarily proposing that everything
> > be done thru SQL. (If we were using a more powerful query language,
> > then perhaps it could be intregrated.)
>
> That is exactly the point. Your RM is too weak to be a viable paradigm.
Not doing the whole thing is not necessarily being "weak". It is a
matter of specialization, which is common in the human world. A
one-size-fits-all language or paradigm is perhaps an unrealistic dream.
RM could be made Turing Complete with a few minor modifications, but I
don't think that is beneficial.
> A more powerful language probably could, but *only* if it were properly
> typed.
>
I would like to see a demonstration within my domain before I believe
that.
> >> Otherwise, you
> >> get Russell's paradox. In your RM the type of relations [table] is not the
> >> type of x's [integer, string, etc]. So far so good. But an envelope can be
> >> put into another! See the problem? You physically cannot do it in your
> >> system. You need referential types like table_ref among integer, string,
> >> etc first class types, or, equivalently, you need a hierarchy of types:
> >> table_of_tables, table_of_tables_of tables, etc.
> >
> > I already argued that "types" are for the most part orthogonal to RM.
>
> You clamed it without giving anything in support of the claim. So far I saw
> no single argument beyond "show me a case", "no math", "it's not biz."
Well, the default is not your position either. I don't see anywhere
where relational *must* be connected to types. Other than requiring at
least one "adaptor" to deliver boolean answers, relational does not
have to care what is in the "cells" of the tables. It mostly just
passes them along as-is or via the "domain math" operating on a real or
virtual row. If you have an example of it having to care, then please
show it.
>
> > I agree that existing implementations are limited in that regard, but I
> > would rather have dynamic or type-free DB's anyhow.
>
> That changes nothing. Mathematically the time when you *can* determine the
> type is irrelevant.
It can get into the issue of the definition of "types".
>
> >> This is what all modern
> >> type systems do. And this is irrelevant to RM vs. OO controversy.
> >
> > Well, type-centricity is not necessary to produce software. Some dig
> > heavy typing, others like me would rather do away with it.
>
> Software engineering is for producing software.
I don't see what your answer is in response to.
>
> > I would like to see a practical manifestation of the alleged problems.
>
> See the librarian paradox as an example.
I'll get back to you on that.
>
> > Matching math to the real world is always going to be an imperfect
> > marriage because the real world is messier than math that tries to
> > model it the vast majority of times.
>
> What do you have instead of mathematics? Knitting?
I am just saying that being tied to mathematical purity of concept is
no guarentee of being practical. You may argue it is a prerequisite,
but because there are many "math ways", a prerequisite is not a
guarentee.
>
> >> So whether you like it or not, but you cannot make RM a paradigm without an
> >> elaborated types system. I saw no RM proponent, except you, who would deny
> >> this trivial fact.
> >
> > If it is trivial, then let's see a trivial demonstration.
>
> Just write a program that creates power set of a given set.
Not unless I see a practical and common need. "Your language is no
good because it takes to long too model Kline Bottles" is of little
practical use if that is not what one does with the tool.
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> Which is completely irrelevant to A and B. Those are *requirements*. As for
>> design, no, you won't get that contract, just because of B, which reads:
>> "quality of service gradually influences the value of." If the system isn't
>> 24-hours available you won't get a penny for it.
>
> Centralization and reliability are not necessarily at odds. One can
> have mirrored drives, realtime DB replication, etc.
Bingo! How are you going to replicate something without distribution? What
is the meaning of "replication"?
>>> No. It looks like we will have a difficult time coming up with a mutual
>>> example here. How about the airline reservation system mentioned.
>>
>> Fine, write a communication protocol in *your* RM.
>
> Again, I won't really defend RM outside my domain of expertise. (It can
> probably be done, but I don't have enough experience in comm to do it
> quickly here.)
You don't need any expertise, that's the point. If RM's decomposition
worked, you would just show how the problem relied on communication could
be decomposed and leave implementation to others. In other words, you would
identify "communication" component of the problem and describe it in the
solution space. This works with ADTs, it does not in your RM. Each time you
refer to predefined types, operations, stored procedures etc, it is an
*ADT* decomposition!
>>> You are correct, I did not define typical or common set operators here.
>>> But that is an implementation detail to be implemented with stored
>>> procedures or app API's. I am not necessarily proposing that everything
>>> be done thru SQL. (If we were using a more powerful query language,
>>> then perhaps it could be intregrated.)
>>
>> That is exactly the point. Your RM is too weak to be a viable paradigm.
>
> Not doing the whole thing is not necessarily being "weak". It is a
> matter of specialization, which is common in the human world. A
> one-size-fits-all language or paradigm is perhaps an unrealistic dream.
No. See above. Specialization is a process of attuning something more
general. It is again the same question about decomposition. First, you need
to present a framework in which you can say: Y is a specialized X. Before
that there is no any specialization.
RM is a specialized ADT system, because I can identify the types (table,
column, row, cell) and exhaustively describe them. Types system is a
framework suitable to deal with any RM. The reverse is wrong. You *cannot*
specialize *your* RM to identify types, you cannot RM-decompose systems
that use such trivial things as communication protocols.
>> A more powerful language probably could, but *only* if it were properly
>> typed.
>
> I would like to see a demonstration within my domain before I believe
> that.
Communication protocols are waiting for you.
> Well, the default is not your position either. I don't see anywhere
> where relational *must* be connected to types. Other than requiring at
> least one "adaptor" to deliver boolean answers, relational does not
> have to care what is in the "cells" of the tables. It mostly just
> passes them along as-is or via the "domain math" operating on a real or
> virtual row.
That's generic programming. A generic container does not care about the
types of its elements. This does not mean that the container itself can be
untyped. You have to specify which objects can be passed as-is. That
constitutes a type. Is a table of that type? In your RM it is obviously
not. So you have at least two types. q.e.d.
>>>> This is what all modern
>>>> type systems do. And this is irrelevant to RM vs. OO controversy.
>>>
>>> Well, type-centricity is not necessary to produce software. Some dig
>>> heavy typing, others like me would rather do away with it.
>>
>> Software engineering is for producing software.
>
> I don't see what your answer is in response to.
That you have changed the subject. It is not about software construction.
It is way before that. Mathematics does not construct anything physical.
Neither type systems do.
>>> Matching math to the real world is always going to be an imperfect
>>> marriage because the real world is messier than math that tries to
>>> model it the vast majority of times.
>>
>> What do you have instead of mathematics? Knitting?
>
> I am just saying that being tied to mathematical purity of concept is
> no guarentee of being practical. You may argue it is a prerequisite,
> but because there are many "math ways", a prerequisite is not a
> guarentee.
I agree with that.
But the point is that to compare things like RM and OO you need a language,
and this language is mathematics. Statements like "this worked to me" have
no deductive prover.
>>>> So whether you like it or not, but you cannot make RM a paradigm without an
>>>> elaborated types system. I saw no RM proponent, except you, who would deny
>>>> this trivial fact.
>>>
>>> If it is trivial, then let's see a trivial demonstration.
>>
>> Just write a program that creates power set of a given set.
>
> Not unless I see a practical and common need. "Your language is no
> good because it takes to long too model Kline Bottles" is of little
> practical use if that is not what one does with the tool.
You asked for a trivial demonstration. Then whatever I would take, you
could always answer that it is either non-trivial, non-biz or has no
practical use. Write an XML parser, invert matrix, make histogram of an
image, search kd-tree...
--
Regards,
Dmitry A. Kazakov
Robert Martin
> Hi all,
>
> What is the best way to implement the following search
>
> Give me all companies that start with "Micro" in Seattle, Washington
>
> Class Company
> {
> String companyName;
> Set locations;
>
> public void addLocation(location)
> {};
> }
>
> In the database world, this is a simple join across two tables.
>
> What is the correct correlation of this in a Object Oriented World.
The word "Correct" is probably inappropriate. There are a number of
correct ways. One good way is to create a new class named CompanyQuery
that has methods that represent the kinds of queries you'd like to do.
public class CompanyQuery {
List<Company> getCompaniesThatStartWith(String prefix){...}
}
Indeed, if you made this into an interface, then you could implement it
many different ways. Then the fact that you were using an RDB would be
irrelevant to the rest of the program. (a good thing!)
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716 |
Robert Martin
> Hi,
> as the lack of replies indicates, there are no good solution for your
> problem. OOA/D does not provide any tools for non-trivial searches like
> your. Using OOA/D, the standard solution would be to create a
> findByNameStartingWithAndByLocation()-method in the Company class. The
> implementation of the find-method would use SQL.
>
> Many OO evangelists claim that searches are not needed in well design
> OO applications. You have to redesign your application to avoid the
> scenario above. Obviously reporting, etc, should not be done using
> OOA/D.
> Fredrik Bertilsson
> http://moonbird.sourceforge.net
Ridiculous. OO and RDB coexist very nicely together. I've never heard
anyone suggest that searches aren't needed.
The big problem with OO and RDB is that people try to make them
represent each other. RDB is about data structure an OO is about
behavior structure. The objects in an OO program should NOT be the
tables in the RDB. The objects in the OO program should MANIPULATE the
data structures from the RDB.
Robert Martin
> Even if
> persistence is not needed, the query and transaction features of a
> RDBMS would still be useful.
This is both true and irrelevant. A good query language (like SQL) is
always useful. It does not preclude the use of OO to structure the
behavior of the system. Indeed, it faciliates OO since you don't have
to design the searching structures.
Robert Martin
> In fact, the OO paradigm for instantiating relationships often allows
> one to avoid searches altogether. That's because the solution is
> tailored to a particular problem. So if the only subset of [Location]
> that is ever of interest to the problem solution is those locations
> starting with "Micro", one would create a separate collection for those
> entries that begin with "Micro".
The OP was asking a simple question. It seemed clear to me that it was
a matter of "Where do I put the SQL?". I don't think that creating a
separate collection of entries that begin with "Micro" answers that
question since in order to create that collection you still have to
find all the entries that begin with "Micro".
fre...@gmail.com
Shouldn't it be
getCompaniesByLocationThatStartWidth(String location, String prefix)
?
Don't you think he will end up with 20 methods
getCompaniesByXAndByYAndByZ(x, y, z)
that are probably called from only one point in the application?
Following statement
"select * from company where location=? and name like ?"
does not reveal that a RDB is used either. The execution of this query
could be implemented in many different ways.
> Then the fact that you were using an RDB would be
> irrelevant to the rest of the program. (a good thing!)
Why? Because you want to use something else but a RDB?
Fredrik Bertilsson
http://frebe.php0h.com
topmind
> On 27 May 2006 23:39:45 -0700, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
>
> >> Which is completely irrelevant to A and B. Those are *requirements*. As for
> >> design, no, you won't get that contract, just because of B, which reads:
> >> "quality of service gradually influences the value of." If the system isn't
> >> 24-hours available you won't get a penny for it.
> >
> > Centralization and reliability are not necessarily at odds. One can
> > have mirrored drives, realtime DB replication, etc.
>
> Bingo! How are you going to replicate something without distribution? What
> is the meaning of "replication"?
Perhaps we need to make a distinction here between distributed backups
and "live" distributed. Generally it is simpler to have one and only
one primary "live process". The mirroring to distance sites is for
emergancy purposes.
However, I suppose that the mirrored sites can serve as historical
research systems, such as a data warehouse kind of thing.
>
> >>> No. It looks like we will have a difficult time coming up with a mutual
> >>> example here. How about the airline reservation system mentioned.
> >>
> >> Fine, write a communication protocol in *your* RM.
> >
> > Again, I won't really defend RM outside my domain of expertise. (It can
> > probably be done, but I don't have enough experience in comm to do it
> > quickly here.)
>
> You don't need any expertise, that's the point. If RM's decomposition
> worked, you would just show how the problem relied on communication could
> be decomposed and leave implementation to others. In other words, you would
> identify "communication" component of the problem and describe it in the
> solution space. This works with ADTs, it does not in your RM. Each time you
> refer to predefined types, operations, stored procedures etc, it is an
> *ADT* decomposition!
Please clarify. I am not sure what you are getting at here. RM is
generally not a "bahavioral" model, while ADT's are.
>
> >>> You are correct, I did not define typical or common set operators here.
> >>> But that is an implementation detail to be implemented with stored
> >>> procedures or app API's. I am not necessarily proposing that everything
> >>> be done thru SQL. (If we were using a more powerful query language,
> >>> then perhaps it could be intregrated.)
> >>
> >> That is exactly the point. Your RM is too weak to be a viable paradigm.
> >
> > Not doing the whole thing is not necessarily being "weak". It is a
> > matter of specialization, which is common in the human world. A
> > one-size-fits-all language or paradigm is perhaps an unrealistic dream.
>
> No. See above. Specialization is a process of attuning something more
> general. It is again the same question about decomposition. First, you need
> to present a framework in which you can say: Y is a specialized X. Before
> that there is no any specialization.
It is not a matter of creating or being subsets. A cook may be able to
serve resturant tables and a server may be able to cook, but generally
they specialize in larger restaurants. Specialization allows tools to
work where they work best. As mentioned above, RM is not an extensive
behavioral modelling tool and generally leaves that to other tools.
>
> RM is a specialized ADT system, because I can identify the types (table,
> column, row, cell) and exhaustively describe them. Types system is a
> framework suitable to deal with any RM. The reverse is wrong. You *cannot*
> specialize *your* RM to identify types, you cannot RM-decompose systems
> that use such trivial things as communication protocols.
Again, being a subset or superset is not the issue. Having more rules
may make something technically a subset, but also results in more
consistent designs. Saying that A has more practical utility than B
because A is a superset of B is not a truism.
Goto's perhaps may be more generic than nested blocks in a programming
language. However, it is tough to work with them for most humans
because they offer no consistency.
Like I said, with a few tweaks, RM could be made Turing Complete and
could execute anything that any other programming language or tool
could. But, I question the practical utility of such.
> > Well, the default is not your position either. I don't see anywhere
> > where relational *must* be connected to types. Other than requiring at
> > least one "adaptor" to deliver boolean answers, relational does not
> > have to care what is in the "cells" of the tables. It mostly just
> > passes them along as-is or via the "domain math" operating on a real or
> > virtual row.
>
> That's generic programming. A generic container does not care about the
> types of its elements. This does not mean that the container itself can be
> untyped. You have to specify which objects can be passed as-is. That
> constitutes a type. Is a table of that type? In your RM it is obviously
> not. So you have at least two types. q.e.d.
Perhaps. I agree that at the "root" level that a base set of
fundimental types may indeed be needed. However, to automatically
extrapolate this to "types everywhere" is bad reasoning.
> >>> Matching math to the real world is always going to be an imperfect
> >>> marriage because the real world is messier than math that tries to
> >>> model it the vast majority of times.
> >>
> >> What do you have instead of mathematics? Knitting?
> >
> > I am just saying that being tied to mathematical purity of concept is
> > no guarentee of being practical. You may argue it is a prerequisite,
> > but because there are many "math ways", a prerequisite is not a
> > guarentee.
>
> I agree with that.
>
> But the point is that to compare things like RM and OO you need a language,
> and this language is mathematics. Statements like "this worked to me" have
> no deductive prover.
Not all practical things are describable in a mathematical sense. And
being "nice" mathematically does not automatically translate into good
practical use. If that means we have to test it in a specific
programming language(s), then so be it.
>
> >>>> So whether you like it or not, but you cannot make RM a paradigm without an
> >>>> elaborated types system. I saw no RM proponent, except you, who would deny
> >>>> this trivial fact.
> >>>
> >>> If it is trivial, then let's see a trivial demonstration.
> >>
> >> Just write a program that creates power set of a given set.
> >
> > Not unless I see a practical and common need. "Your language is no
> > good because it takes to long too model Kline Bottles" is of little
> > practical use if that is not what one does with the tool.
>
> You asked for a trivial demonstration. Then whatever I would take, you
> could always answer that it is either non-trivial, non-biz or has no
> practical use. Write an XML parser, invert matrix, make histogram of an
> image, search kd-tree...
University lab toys are often not good tests for real-world utility.
It is not too much to ask for practical utility of something. And, I am
not familiar enough with systems software to make recommendations about
what is useful and what isn't. Thus, I am not sure what you are
complaining about.
As far as the Librarian Paradox, that seems like a problem with
conflicting/bad requirements. If your boss or users asks for something
contradictory, then you ask for clarification or a decision about which
of multiple paths to take.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
-T-
fre...@gmail.com
> I've never heard anyone suggest that searches aren't needed.
I suggest that you read the posts from HS Lahman in this thread.
> RDB is about data structure an OO is about behavior structure.
An RDB has a lot of behvior too, integrity checking, transactions, etc.
> The objects in an OO program should NOT be the tables in the RDB.
Why? Look at how people use Hibernate. Mostly there are 1:1 mapping
between class and table.
> The objects in the OO program should MANIPULATE the data structures
> from the RDB.
Doesn't the objects also contains the data from table records?
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> Indeed, it faciliates OO since you don't have to design the searching
> structures.
Please clarify.
Fredrik Bertilsson
http://frebe.php0h.com
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On 27 May 2006 23:39:45 -0700, topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>
>>>> Which is completely irrelevant to A and B. Those are *requirements*. As for
>>>> design, no, you won't get that contract, just because of B, which reads:
>>>> "quality of service gradually influences the value of." If the system isn't
>>>> 24-hours available you won't get a penny for it.
>>>
>>> Centralization and reliability are not necessarily at odds. One can
>>> have mirrored drives, realtime DB replication, etc.
>>
>> Bingo! How are you going to replicate something without distribution? What
>> is the meaning of "replication"?
>
> Perhaps we need to make a distinction here between distributed backups
> and "live" distributed.
LOL! Whatever it might be, it is *distributed*.
>>>>> No. It looks like we will have a difficult time coming up with a mutual
>>>>> example here. How about the airline reservation system mentioned.
>>>>
>>>> Fine, write a communication protocol in *your* RM.
>>>
>>> Again, I won't really defend RM outside my domain of expertise. (It can
>>> probably be done, but I don't have enough experience in comm to do it
>>> quickly here.)
>>
>> You don't need any expertise, that's the point. If RM's decomposition
>> worked, you would just show how the problem relied on communication could
>> be decomposed and leave implementation to others. In other words, you would
>> identify "communication" component of the problem and describe it in the
>> solution space. This works with ADTs, it does not in your RM. Each time you
>> refer to predefined types, operations, stored procedures etc, it is an
>> *ADT* decomposition!
>
> Please clarify. I am not sure what you are getting at here.
Take the distribution example. RM decomposition is based on tables. So let
"live process" be table 1, other processes be table 2, communication, hmm,
is table 3. Care to continue? (:-))
>>>>> You are correct, I did not define typical or common set operators here.
>>>>> But that is an implementation detail to be implemented with stored
>>>>> procedures or app API's. I am not necessarily proposing that everything
>>>>> be done thru SQL. (If we were using a more powerful query language,
>>>>> then perhaps it could be intregrated.)
>>>>
>>>> That is exactly the point. Your RM is too weak to be a viable paradigm.
>>>
>>> Not doing the whole thing is not necessarily being "weak". It is a
>>> matter of specialization, which is common in the human world. A
>>> one-size-fits-all language or paradigm is perhaps an unrealistic dream.
>>
>> No. See above. Specialization is a process of attuning something more
>> general. It is again the same question about decomposition. First, you need
>> to present a framework in which you can say: Y is a specialized X. Before
>> that there is no any specialization.
>
> It is not a matter of creating or being subsets. A cook may be able to
> serve resturant tables and a server may be able to cook, but generally
> they specialize in larger restaurants.
Specializing in doing *what*? Answer: cooking. That's what is specialized
in. So don't sell me your used rusty can-opener for cooking theory!
>>> Well, the default is not your position either. I don't see anywhere
>>> where relational *must* be connected to types. Other than requiring at
>>> least one "adaptor" to deliver boolean answers, relational does not
>>> have to care what is in the "cells" of the tables. It mostly just
>>> passes them along as-is or via the "domain math" operating on a real or
>>> virtual row.
>>
>> That's generic programming. A generic container does not care about the
>> types of its elements. This does not mean that the container itself can be
>> untyped. You have to specify which objects can be passed as-is. That
>> constitutes a type. Is a table of that type? In your RM it is obviously
>> not. So you have at least two types. q.e.d.
>
> Perhaps. I agree that at the "root" level that a base set of
> fundimental types may indeed be needed. However, to automatically
> extrapolate this to "types everywhere" is bad reasoning.
It is not. It is the only one possible reasoning. You can argue that in
your application domain of cooking, concentrated solely on can opening,
there is only one type of food (as found in cans). Though I doubt that.
>> But the point is that to compare things like RM and OO you need a language,
>> and this language is mathematics. Statements like "this worked to me" have
>> no deductive prover.
>
> Not all practical things are describable in a mathematical sense.
In which sense they are? Knitting again?
>> You asked for a trivial demonstration. Then whatever I would take, you
>> could always answer that it is either non-trivial, non-biz or has no
>> practical use. Write an XML parser, invert matrix, make histogram of an
>> image, search kd-tree...
>
> University lab toys are often not good tests for real-world utility.
> It is not too much to ask for practical utility of something. And, I am
> not familiar enough with systems software to make recommendations about
> what is useful and what isn't. Thus, I am not sure what you are
> complaining about.
I am not complaining, I am trying explain why your arguments will never be
seriously considered by anybody. One cannot argument outside any logical
system. Reasoning is a part of logic. "Show me a practical example where
the Earth isn't flat", that wouldn't impress anybody to give you a contract
for mining cheese on the Moon. Even if you said that you'd use balloons,
because rockets are so dangerously impractical...
> As far as the Librarian Paradox, that seems like a problem with
> conflicting/bad requirements. If your boss or users asks for something
> contradictory, then you ask for clarification or a decision about which
> of multiple paths to take.
And how do you know if a requirement contradictory?
Alfredo Novoa
Robert Martin ha escrito:
> Ridiculous. OO and RDB coexist very nicely together. I've never heard
> anyone suggest that searches aren't needed.
Relational databases have nothing to do with searches. This shows
profound ignorance about data management theory.
> The big problem with OO and RDB is that people try to make them
> represent each other. RDB is about data structure an OO is about
> behavior structure.
No no no! RDB is about data management and OO is about application
programming.
The DBMS must enforce all the business rules (data behavior). The OO
applications must enforce the presentation and communication behavior.
> The objects in an OO program should NOT be the
> tables in the RDB.
Obviously true.
> The objects in the OO program should MANIPULATE the
> data structures from the RDB.
Very wrong. The OO program should TRANSFORM the user input in orders
for the DBMS.
The OO program is an interface between the users and the DBMS. A
friendly substitute for the DBMS console.
Regards
Alfredo
Robert Martin
>> OO and RDB coexist very nicely together.
> Agree. The problem is that not all OO purists agree to this.
Purists don't write code for a living.
>
>> I've never heard anyone suggest that searches aren't needed.
> I suggest that you read the posts from HS Lahman in this thread.
They are too long. But I DID see his post recently where he offered
one solution which involved setting up a structure that did not involve
searching. I chided him for that since all he really did was defer
the searching to the function that set up the structure. Still, the
notion of tuned data structures, or pre-queried data structures is not
a bad one. But it's not the universal solution.
>
>> RDB is about data structure an OO is about behavior structure.
> An RDB has a lot of behvior too, integrity checking, transactions, etc.
RDBs may have this behavior; but it is behavior related to the
structure of the data.
>
>> The objects in an OO program should NOT be the tables in the RDB.
> Why? Look at how people use Hibernate. Mostly there are 1:1 mapping
> between class and table.
Naively, IMHO. There can be a correspondence between the application
objects and the database tables; but that correspondence should not be
demanded or expected. Nor should that correspondence be a desgin
constraint. Rather the data tables, and aplication classes should be
isolated from each other and designed for their own reasons. Any
residual correspondence is serendipity.
>
>> The objects in the OO program should MANIPULATE the data structures
>> from the RDB.
> Doesn't the objects also contains the data from table records?
Perhaps. They may also contain data that relates to the behavior, and
that did not come from the tables. Moreover, the data in an object may
come from more than one table; and the data in a table may not be held
by one object. Some data in the tables may not be held by any of the
objects.
Objects and tables cross cut each other. They are not the same thing.
Database tables are not just objects stripped of their behavior. They
are partitioned for very different reasons, and no correspondence
should be forced.