Why OOP Fails Domain Modeling

On Sat, 23 Aug 2008 04:42:31 UTC, topmind <topmind@technologist.com>
wrote:
> It's time to start focusing on the best tool for the job instead of
> purity or singularity of view. Some complain that SQL is a messy,
> ugly, unnatural language that is hard to work with. OOP is to them a
> better match for how developers view the world than SQL.
>
If you're going to go this far in the name of relational, then you
should at least advocate something more truly relational than SQL.
I'll defer any comments to the writings of Fabian Pascal, C.J.Date,
and Hugh Darwen on the subject.

Lahman should have given you a pass on this one, since he'd probably
agree that the state of the art in OOPL does a very poor job of
properly defining domains. At least you limited it to OOP and not
encompassing all of OT.

--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com

"topmind" <topmind@technologist.com> wrote in message
news:eb83cca3-de4a-488c-89e4-a84ac33c2da4@n38g2000prl.googlegroups.com...

> S Perryman wrote:

>> "topmind" <topmind@technologist.com> wrote in message
>> news:922fce20-1853-402e-bcc6-ca7be6909c0e@r35g2000prm.googlegroups.com...

>>> Domain abstractions are things like customers, products, shopping
>>> carts, vendors, employees, invoices, inventory, etc. OOP has for the
>>> most part failed this side of modeling so far. It's reasonable success
>>> at CA cannot be recreated on the DA side. Even a fair amount of OOP
>>> fans I often debate agree with me more or less on this fact.

>> Domain abstractions are things like :

>> subscriber, mobile phone, optical fibre, multiplexer, base station,
>> switch,
>> communications connection, router, line card etc.

>> OOP has for the most part succeeded this side of modelling so far.
>> Its reasonable success at CA has been recreated on the DA side.
>> Even a fair amount of OOP detractors I often debate with agree with me or
>> less on this fact.

> That's because you guys couldn't figure out how to use a RDBMS right
> for your telecom niche, so you instead rolled your own half-ass custom
> OODBMS with with lovely pointer-hopping-hell.

1. Completely unrelated to what I have written above (which kills your
claims
about OO and "DA" ) .

2. The RDBMS "guys" couldn't use their beloved systems to incorporate
both polymorphic info storage and behaviour access, together with their
only
procedural hammer (the "variant" record) , to provide the system
performance and
code flexibility that the telecoms domains required.

Or to paraphrase you :

They instead rolled their own half-arsed custom meta-typing, type
substitutability
systems with lovely masses of "case statements" + "type ids stored in the
RDBMS"
hell.


Regards,
Steven Perryman

On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
> "topmind" <topm...@technologist.com> wrote in message
>
> news:eb83cca3-de4a-488c-89e4-a84ac33c2da4@n38g2000prl.googlegroups.com...
>
>
>
> > S Perryman wrote:
> >> "topmind" <topm...@technologist.com> wrote in message
> >>news:922fce20-1853-402e-bcc6-ca7be6909c0e@r35g2000prm.googlegroups.com...
> >>> Domain abstractions are things like customers, products, shopping
> >>> carts, vendors, employees, invoices, inventory, etc. OOP has for the
> >>> most part failed this side of modeling so far. It's reasonable success
> >>> at CA cannot be recreated on the DA side. Even a fair amount of OOP
> >>> fans I often debate agree with me more or less on this fact.
> >> Domain abstractions are things like :
> >> subscriber, mobile phone, optical fibre, multiplexer, base station,
> >> switch,
> >> communications connection, router, line card etc.
> >> OOP has for the most part succeeded this side of modelling so far.
> >> Its reasonable success at CA has been recreated on the DA side.
> >> Even a fair amount of OOP detractors I often debate with agree with me or
> >> less on this fact.
> > That's because you guys couldn't figure out how to use a RDBMS right
> > for your telecom niche, so you instead rolled your own half-ass custom
> > OODBMS with with lovely pointer-hopping-hell.
>
> 1. Completely unrelated to what I have written above (which kills your
> claims
> about OO and "DA" ) .

Improve your writing.

>
> 2. The RDBMS "guys" couldn't use their beloved systems to incorporate
> both polymorphic info storage and behaviour access, together with their
> only
> procedural hammer (the "variant" record) , to provide the system
> performance and
> code flexibility that the telecoms domains required.

Based on your library media example a year or so ago, I can see why
you'd tie yourself in a knot. Your static RAMmy thinking gets you
stuck.

>
> Or to paraphrase you :
>
> They instead rolled their own half-arsed custom meta-typing, type
> substitutability
> systems with lovely masses of "case statements" + "type ids stored in the
> RDBMS"
> hell.

That's what you said about the library example, and I proved you flat
wrong and enjoyed proving you flat wrong because you are stubborn and
narrow-minded. You are a poor designer and I wouldn't want to touch
your crap with an 80-foot telephone pole.

Do we need to review the library example again, or have you had enough
wippin's?

Variant Shmariant.

>
> Regards,
> Steven Perryman

-T-

On Aug 25, 6:59 pm, "Lee Riemenschneider" <newsu...@frogooa.com>
wrote:
> On Sat, 23 Aug 2008 04:42:31 UTC, topmind <topm...@technologist.com>
> wrote:> It's time to start focusing on the best tool for the job instead of
> > purity or singularity of view. Some complain that SQL is a messy,
> > ugly, unnatural language that is hard to work with. OOP is to them a
> > better match for how developers view the world than SQL.
>
> If you're going to go this far in the name of relational, then you
> should at least advocate something more truly relational than SQL.
> I'll defer any comments to the writings of Fabian Pascal, C.J.Date,
> and Hugh Darwen on the subject.

I was trying to stay somewhat grounded in reality and focus on what
RDBMS offer in the shorter term. If/when better RDBMS and/or query
languages come out, then there will be even more options for domain
modeling.

>
> Lahman should have given you a pass on this one, since he'd probably
> agree that the state of the art in OOPL does a very poor job of
> properly defining domains. At least you limited it to OOP and not
> encompassing all of OT.
>
> --
> Lee W. Riemenschneider
> GO BOILERS!
> Running eComStation (eCS)(the latest incarnation of OS/2)
> Buy eCS everyone! Buy it now! http://www.ecomstation.com

-T-

"topmind" <topmind@technologist.com> wrote in message
news:d77e145a-bacd-429a-99c5-fdd41341e31c@o40g2000prn.googlegroups.com...

> On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:

SP> OOP has for the most part succeeded this side of modelling so far.
SP> Its reasonable success at CA has been recreated on the DA side.
SP> Even a fair amount of OOP detractors I often debate with agree with me
or
SP> less on this fact.

TM> That's because you guys couldn't figure out how to use a RDBMS right
TM> for your telecom niche, so you instead rolled your own half-ass custom
TM> OODBMS with with lovely pointer-hopping-hell.

>> 1. Completely unrelated to what I have written above (which kills your
>> claims about OO and "DA" ) .

> Improve your writing.

Still haven't got that basic command of English yet, have you.

Your rubbish about "rolled" etc has absolutely nothing to do with the
comment that OO is as successful on the "DA" side as the "CA" side.


>> 2. The RDBMS "guys" couldn't use their beloved systems to incorporate
>> both polymorphic info storage and behaviour access, together with
>> their
>> only procedural hammer (the "variant" record) , to provide the system
>> performance and code flexibility that the telecoms domains required.

> Based on your library media example a year or so ago, I can see why
> you'd tie yourself in a knot. Your static RAMmy thinking gets you
> stuck.

I'm describing your solution, not mine. How very silly of you (again) .


>> Or to paraphrase you :

>> They instead rolled their own half-arsed custom meta-typing, type
>> substitutability
>> systems with lovely masses of "case statements" + "type ids stored in the
>> RDBMS" hell.

> That's what you said about the library example, and I proved you flat
> wrong and enjoyed proving you flat wrong because you are stubborn and
> narrow-minded. You are a poor designer and I wouldn't want to touch
> your crap with an 80-foot telephone pole.

> Do we need to review the library example again, or have you had enough
> wippin's?

1. No need. Your embarrassingly amusing prevarications are on record :

http://groups.google.com/group/comp....2b9751ef677e0d


2. Goto "real-world systems" .

Which, given the Library example was a very stripped down version of
something
that has been done for years in telecom nw management systems using OOP (ie
systems that control various kinds of *real equipment* that have different
hw/protocol implementations for properties possessed by *different and/or
same*
types of entity) ...

What was your solution again ??
Oh thats' right. Your half-baked incomplete solution assumes that :

- all the properties of every entity was pure data, and not behaviour

- and that the data representation for any property common to more than
one entity was the same for all entity types

So you could not even provide a "P/R" solution for a real-world problem
stripped down to the level that a little kid can understand it.


But anyway, I can see why you want to thrash around elsewhere (as always) .
Your claims about OOP failing domain modelling have been shown to be
your usual ignorant un-researched rubbish.


Regards,
Steven Perryman

S Perryman wrote:
> "topmind" <topmind@technologist.com> wrote in message
> news:d77e145a-bacd-429a-99c5-fdd41341e31c@o40g2000prn.googlegroups.com...
>
> > On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
>
> SP> OOP has for the most part succeeded this side of modelling so far.
> SP> Its reasonable success at CA has been recreated on the DA side.
> SP> Even a fair amount of OOP detractors I often debate with agree with me
> or
> SP> less on this fact.
>
> TM> That's because you guys couldn't figure out how to use a RDBMS right
> TM> for your telecom niche, so you instead rolled your own half-ass custom
> TM> OODBMS with with lovely pointer-hopping-hell.
>
> >> 1. Completely unrelated to what I have written above (which kills your
> >> claims about OO and "DA" ) .
>
> > Improve your writing.
>
> Still haven't got that basic command of English yet, have you.

Projecting.

> >> Or to paraphrase you :
>
> >> They instead rolled their own half-arsed custom meta-typing, type
> >> substitutability
> >> systems with lovely masses of "case statements" + "type ids stored in the
> >> RDBMS" hell.
>
> > That's what you said about the library example, and I proved you flat
> > wrong and enjoyed proving you flat wrong because you are stubborn and
> > narrow-minded. You are a poor designer and I wouldn't want to touch
> > your crap with an 80-foot telephone pole.
>
> > Do we need to review the library example again, or have you had enough
> > wippin's?
>
> 1. No need. Your embarrassingly amusing prevarications are on record :
>
> http://groups.google.com/group/comp....2b9751ef677e0d
>

You claimed there would be a "combinatorial explosion" and there
WASN'T any. You tried to later stretch the definition of C.E. to force
one to "exist" using null-play word games. You got pounded there. Live
with your mental wound; you were shown up. Accept it like man.

>
> 2. Goto "real-world systems" .
>
> Which, given the Library example was a very stripped down version of
> something
> that has been done for years in telecom nw management systems using OOP (ie
> systems that control various kinds of *real equipment* that have different
> hw/protocol implementations for properties possessed by *different and/or
> same*
> types of entity) ...
>
> What was your solution again ??
> Oh thats' right. Your half-baked incomplete solution assumes that :
>
> - all the properties of every entity was pure data, and not behaviour

And that's a bad thing? Tons of repetitious set/gets is mindless code-
bloating repetition that cranks up development cost and makes
programmers drool out of boredom and get carpel tunnel.

>
> - and that the data representation for any property common to more than
> one entity was the same for all entity types

Why is this a bad thing? If you want a different one, you make a
different one. It also depends how its implemented: I showed 2
different approaches one could take to boost different factors
depending on customer patterns of change.

>
> So you could not even provide a "P/R" solution for a real-world problem
> stripped down to the level that a little kid can understand it.
>

It was better then yours.

>
> But anyway, I can see why you want to thrash around elsewhere (as always) .
> Your claims about OOP failing domain modelling have been shown to be
> your usual ignorant un-researched rubbish.

Projecting. You make bloated verbose crap for job security.

>
>
> Regards,
> Steven Perryman

-T-

"topmind" <topmind@technologist.com> wrote in message
news:a3b1e334-c15c-441a-b600-49a622946a7a@b2g2000prf.googlegroups.com...

> S Perryman wrote:
>> "topmind" <topmind@technologist.com> wrote in message
>> news:d77e145a-bacd-429a-99c5-fdd41341e31c@o40g2000prn.googlegroups.com...
>>
>> > On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
>>
>> SP> OOP has for the most part succeeded this side of modelling so far.
>> SP> Its reasonable success at CA has been recreated on the DA side.
>> SP> Even a fair amount of OOP detractors I often debate with agree with
>> me
>> or
>> SP> less on this fact.
>>
>> TM> That's because you guys couldn't figure out how to use a RDBMS right
>> TM> for your telecom niche, so you instead rolled your own half-ass
>> custom
>> TM> OODBMS with with lovely pointer-hopping-hell.
>>
SP> 1. Completely unrelated to what I have written above (which kills your
SP> claims about OO and "DA" ) .

TM> Improve your writing.

>> Still haven't got that basic command of English yet, have you.

> Projecting.

Your usual careful snipping of the relevant text (as always) .
I'll put back anyway, as it marks your original thread topic as dead.

<quote+1>

Your rubbish about "rolled" etc has absolutely nothing to do with the
comment that OO is as successful on the "DA" side as the "CA" side.

</quote>


Now we can return to your usual diversionary tactics ...

SP> They instead rolled their own half-arsed custom meta-typing, type
SP> substitutability
SP> systems with lovely masses of "case statements" + "type ids stored in
the
SP> RDBMS" hell.

TM> That's what you said about the library example, and I proved you flat
TM> wrong and enjoyed proving you flat wrong because you are stubborn and
TM> narrow-minded. You are a poor designer and I wouldn't want to touch
TM> your crap with an 80-foot telephone pole.

TM> Do we need to review the library example again, or have you had enough
TM> wippin's?

>> 1. No need. Your embarrassingly amusing prevarications are on record :

>> http://groups.google.com/group/comp....2b9751ef677e0d

> You claimed there would be a "combinatorial explosion" and there
> WASN'T any. You tried to later stretch the definition of C.E. to force
> one to "exist" using null-play word games. You got pounded there. Live
> with your mental wound; you were shown up. Accept it like man.

Tis all there for people to see.

1. The stripped down example had 5 entity types, about 10 property types,
3 of which were shared.

So a '10 x 5' problem.

And for the *real-world* problem. 100+ different entity types, 100+
different properties.

1. So a '100+ x 100+' = *10000+* problem.
Hmm, for a small change in the entity and property sets (5 to 100+ , 10 to
100+ ) ,
a two orders of magnitude increase in the permutation space.

The maths domain has a description for such occurrences ...


2. What does your (not actually a complete equivalent of my OO) "solution"
look like for the *real-world* problem ??

One that had millions of instances of the various entity types.


>> 2. Goto "real-world systems" .
>> Which, given the Library example was a very stripped down version of
>> something
>> that has been done for years in telecom nw management systems using OOP
>> (ie
>> systems that control various kinds of *real equipment* that have
>> different
>> hw/protocol implementations for properties possessed by *different and/or
>> same* types of entity) ...

>> What was your solution again ??
>> Oh thats' right. Your half-baked incomplete solution assumes that :

>> - all the properties of every entity was pure data, and not behaviour

> And that's a bad thing? Tons of repetitious set/gets is mindless code-
> bloating repetition that cranks up development cost and makes
> programmers drool out of boredom and get carpel tunnel.

#1

>> - and that the data representation for any property common to more than
>> one entity was the same for all entity types

> Why is this a bad thing?

#2

> If you want a different one, you make a
> different one. It also depends how its implemented: I showed 2
> different approaches one could take to boost different factors
> depending on customer patterns of change.

#1 / #2.
Not a bad thing at all in general.

But in the real world, some of the entities/properties are in different
databases (legacy) . Some of the entities/properties in fact are
computational
behaviours that exist on different systems (telecoms equipment etc) .

All these factors affecting the optimal solution.
And the extent of change needed to accommodate these factors.

Does this resemble a real world you have worked in ?? One where :

- instances of the same entity type have different implementation behaviours
based on where in the system they reside ??

- the data representations of entities are not held in the same data
repository,
different repository impls (SQL, OODB etc) ??


>> So you could not even provide a "P/R" solution for a real-world problem
>> stripped down to the level that a little kid can understand it.

> It was better then yours.

Who knows ??
You can't even tell anyone what your "solution" outputs for the given test
inputs. Even when you have been shown what the expected outputs are.
From what I can deduce, it does something completely different.

But as I said, twas a problem that a little kid can understand ...


Regards,
Steven Perryman

On Sep 1, 4:37 am, "S Perryman" <a...@a.net> wrote:
> "topmind" <topm...@technologist.com> wrote in message
>
> news:a3b1e334-c15c-441a-b600-49a622946a7a@b2g2000prf.googlegroups.com...
>
>
>
> > S Perryman wrote:
> >> "topmind" <topm...@technologist.com> wrote in message
> >>news:d77e145a-bacd-429a-99c5-fdd41341e31c@o40g2000prn.googlegroups.com...
>
> >> > On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
>
> >> SP> OOP has for the most part succeeded this side of modelling so far.
> >> SP> Its reasonable success at CA has been recreated on the DA side.
> >> SP> Even a fair amount of OOP detractors I often debate with agree with
> >> me
> >> or
> >> SP> less on this fact.
>
> >> TM> That's because you guys couldn't figure out how to use a RDBMS right
> >> TM> for your telecom niche, so you instead rolled your own half-ass
> >> custom
> >> TM> OODBMS with with lovely pointer-hopping-hell.
>
> SP> 1. Completely unrelated to what I have written above (which kills your
> SP> claims about OO and "DA" ) .
>
> TM> Improve your writing.
>
> >> Still haven't got that basic command of English yet, have you.
> > Projecting.
>
> Your usual careful snipping of the relevant text (as always) .
> I'll put back anyway, as it marks your original thread topic as dead.
>
> <quote+1>
>
> Your rubbish about "rolled" etc has absolutely nothing to do with the
> comment that OO is as successful on the "DA" side as the "CA" side.
>
> </quote>
>
> Now we can return to your usual diversionary tactics ...
>
> SP> They instead rolled their own half-arsed custom meta-typing, type
> SP> substitutability
> SP> systems with lovely masses of "case statements" + "type ids stored in
> the
> SP> RDBMS" hell.
>
> TM> That's what you said about the library example, and I proved you flat
> TM> wrong and enjoyed proving you flat wrong because you are stubborn and
> TM> narrow-minded. You are a poor designer and I wouldn't want to touch
> TM> your crap with an 80-foot telephone pole.
>
> TM> Do we need to review the library example again, or have you had enough
> TM> wippin's?
>
> >> 1. No need. Your embarrassingly amusing prevarications are on record :
> >>http://groups.google.com/group/comp....g/f92b9751ef67...
> > You claimed there would be a "combinatorial explosion" and there
> > WASN'T any. You tried to later stretch the definition of C.E. to force
> > one to "exist" using null-play word games. You got pounded there. Live
> > with your mental wound; you were shown up. Accept it like man.
>
> Tis all there for people to see.
>
> 1. The stripped down example had 5 entity types, about 10 property types,
> 3 of which were shared.
>
> So a '10 x 5' problem.
>
> And for the *real-world* problem. 100+ different entity types, 100+
> different properties.
>
> 1. So a '100+ x 100+' = *10000+* problem.
> Hmm, for a small change in the entity and property sets (5 to 100+ , 10 to
> 100+ ) ,
> a two orders of magnitude increase in the permutation space.
>
> The maths domain has a description for such occurrences ...

You forgot already? That's how YOU would do it because you are bad at
procedural/relational programming. That's not how I did it.

There is no need to replicate shared attributes.

>
> 2. What does your (not actually a complete equivalent of my OO) "solution"
> look like for the *real-world* problem ??
>
> One that had millions of instances of the various entity types.
>
> >> 2. Goto "real-world systems" .
> >> Which, given the Library example was a very stripped down version of
> >> something
> >> that has been done for years in telecom nw management systems using OOP
> >> (ie
> >> systems that control various kinds of *real equipment* that have
> >> different
> >> hw/protocol implementations for properties possessed by *different and/or
> >> same* types of entity) ...
> >> What was your solution again ??
> >> Oh thats' right. Your half-baked incomplete solution assumes that :
> >> - all the properties of every entity was pure data, and not behaviour
> > And that's a bad thing? Tons of repetitious set/gets is mindless code-
> > bloating repetition that cranks up development cost and makes
> > programmers drool out of boredom and get carpel tunnel.
>
> #1
>
> >> - and that the data representation for any property common to more than
> >> one entity was the same for all entity types
> > Why is this a bad thing?
>
> #2
>
> > If you want a different one, you make a
> > different one. It also depends how its implemented: I showed 2
> > different approaches one could take to boost different factors
> > depending on customer patterns of change.
>
> #1 / #2.
> Not a bad thing at all in general.
>
> But in the real world, some of the entities/properties are in different
> databases (legacy) . Some of the entities/properties in fact are
> computational
> behaviours that exist on different systems (telecoms equipment etc) .
>
> All these factors affecting the optimal solution.
> And the extent of change needed to accommodate these factors.
>
> Does this resemble a real world you have worked in ?? One where :
>
> - instances of the same entity type have different implementation behaviours
> based on where in the system they reside ??

Without looking at something more specific, it is hard to evaluate
your claims. Your "problems" are often artifacts of your OWN bad
designs.

>
> - the data representations of entities are not held in the same data
> repository,
> different repository impls (SQL, OODB etc) ??
>
> >> So you could not even provide a "P/R" solution for a real-world problem
> >> stripped down to the level that a little kid can understand it.
> > It was better then yours.
>
> Who knows ??
> You can't even tell anyone what your "solution" outputs for the given test
> inputs. Even when you have been shown what the expected outputs are.
> From what I can deduce, it does something completely different.

What are you talking about?

>
> But as I said, twas a problem that a little kid can understand ...
>
> Regards,
> Steven Perryman

-T-

"topmind" <topmind@technologist.com> wrote in message
news:89384a6f-9428-44a4-bd18-22c1d9bc513a@b38g2000prf.googlegroups.com...

> On Sep 1, 4:37 am, "S Perryman" <a...@a.net> wrote:

TM> Do we need to review the library example again, or have you had enough
TM> wippin's?

SP>1. No need. Your embarrassingly amusing prevarications are on record :
SP>http://groups.google.com/group/comp....g/f92b9751ef67...
SP> You claimed there would be a "combinatorial explosion" and there
SP> WASN'T any. You tried to later stretch the definition of C.E. to force
SP> one to "exist" using null-play word games. You got pounded there. Live
SP> with your mental wound; you were shown up. Accept it like man.

>> Tis all there for people to see.

>> 1. The stripped down example had 5 entity types, about 10 property types,
>> 3 of which were shared.

>> So a '10 x 5' problem.

>> And for the *real-world* problem. 100+ different entity types, 100+
>> different properties.

>> 1. So a '100+ x 100+' = *10000+* problem.
>> Hmm, for a small change in the entity and property sets (5 to 100+ , 10
>> to
>> 100+ ) , a two orders of magnitude increase in the permutation space.

>> The maths domain has a description for such occurrences ...

> You forgot already? That's how YOU would do it because you are bad at
> procedural/relational programming. That's not how I did it.

> There is no need to replicate shared attributes.

What rubbish are you writing now !!??
If I have 100+ attr types, what is your "solution" going to be ??

Attributes(EntityInstanceId,Attr1,Attr2, ... Attr100, ... ) ??

Because that is what your "solution" is for the toy-town example.


>> 2. What does your (not actually a complete equivalent of my OO)
>> "solution"
>> look like for the *real-world* problem ??

>> One that had millions of instances of the various entity types.

[ snip ... ]

>> But in the real world, some of the entities/properties are in different
>> databases (legacy) . Some of the entities/properties in fact are
>> computational behaviours that exist on different systems (telecoms
>> equipment etc) .

>> All these factors affecting the optimal solution.
>> And the extent of change needed to accommodate these factors.

>> Does this resemble a real world you have worked in ?? One where :

>> - instances of the same entity type have different implementation
>> behaviours
>> based on where in the system they reside ??

> Without looking at something more specific, it is hard to evaluate
> your claims. Your "problems" are often artifacts of your OWN bad
> designs.

All you have to do is something like the following :

SELECT entity
FROM E
WHERE entity.p1 = X
SET p2 = Y ;

With the unfortunate problem that :

- E may be a set of different databases with different underlying impls

- some of the instances of E may be on physically separate systems

- p1 and p2 may not be data values, but implementation behaviour that does
things with *real equipment*


>> You can't even tell anyone what your "solution" outputs for the given
>> test
>> inputs. Even when you have been shown what the expected outputs are.
>> From what I can deduce, it does something completely different.

> What are you talking about?

As I said (sigh) , twas a problem that a little kid can understand.

Can we spell it out even simpler than that for you ?? We'll try ...

If someone gives me a problem to write s/w to add two numbers, and
when they give me the following inputs :

1,1
2,3

they tell me that they expect to see the following outputs :

2
5

then if I produce something that doesn't appear to add two numbers,
and when asked what my program *does actually produce as output* ,
start ranting that "I don't have to write an add program how you tell me
to" etc, I can rightly expect to be treated as an incompetent fool.

Now, read the original thread again ... and go figure !!!


Regards,
Steven Perryman

On Sep 3, 5:57 am, "S Perryman" <a...@a.net> wrote:
> "topmind" <topm...@technologist.com> wrote in message
>
> news:89384a6f-9428-44a4-bd18-22c1d9bc513a@b38g2000prf.googlegroups.com...
>
> > On Sep 1, 4:37 am, "S Perryman" <a...@a.net> wrote:
>
> TM> Do we need to review the library example again, or have you had enough
> TM> wippin's?
>
> SP>1. No need. Your embarrassingly amusing prevarications are on record :
> SP>http://groups.google.com/group/comp....g/f92b9751ef67...
> SP> You claimed there would be a "combinatorial explosion" and there
> SP> WASN'T any. You tried to later stretch the definition of C.E. to force
> SP> one to "exist" using null-play word games. You got pounded there. Live
> SP> with your mental wound; you were shown up. Accept it like man.
>
> >> Tis all there for people to see.
> >> 1. The stripped down example had 5 entity types, about 10 property types,
> >> 3 of which were shared.
> >> So a '10 x 5' problem.
> >> And for the *real-world* problem. 100+ different entity types, 100+
> >> different properties.
> >> 1. So a '100+ x 100+' = *10000+* problem.
> >> Hmm, for a small change in the entity and property sets (5 to 100+ , 10
> >> to
> >> 100+ ) , a two orders of magnitude increase in the permutation space.
> >> The maths domain has a description for such occurrences ...
> > You forgot already? That's how YOU would do it because you are bad at
> > procedural/relational programming. That's not how I did it.
> > There is no need to replicate shared attributes.
>
> What rubbish are you writing now !!??
> If I have 100+ attr types, what is your "solution" going to be ??
>
> Attributes(EntityInstanceId,Attr1,Attr2, ... Attr100, ... ) ??
>
> Because that is what your "solution" is for the toy-town example.

First, how is that a "combinatorial explosion"?

Second, I offered 2 solutions. The above was only one of them. If the
quantity of attributes changes often, then the 2nd solution would
probably be better.

(I'll reply to other issues later)

-T-

> Regards,
> Steven Perryman