Post #273,914
11/26/06 3:52:45 AM
11/26/06 4:26:27 AM
|
Polymorphism is limited
Attribute driven would have been a non-starter and procedural would have created wonderful switch statements.
Use a combination. Plus, lots of case statements often means you are doing something wrong, but I cannot check without looking at your code. OO'ers often assume you can manage differences using polymorphic sub-type hierarchies. However, hierarchies are not powerful enough for the real world. Primarily because they cannot handle orthogonality well, forcing one into either-or choices and time-consuming to remake into AND-able.
Set theory is more powerful, and better organized than the navigational pointer-like graph-hell that OOP gives you with GOF pasta. In other words, sets are a superior modeling technique to trees; and better organization than graphs (navigational).
And case statements are not necessarily evil. C just makes them ugly with its stupid "break" conventions. This is the fault of C languages, not procedural.
Related:
[link|http://www.c2.com/cgi/wiki?VariationsTendTowardCartesianProduct|http://www.c2.com/cg...dCartesianProduct]
________________
oop.ismad.com
Edited by tablizer
Nov. 26, 2006, 04:26:27 AM EST
|
Post #273,922
11/26/06 8:00:42 AM
|
I'm not a religious zealot
I do not believe one methodology fits all and am mindful of how a technique can affect development and maintainability. In this case, the rules Strategies were handling completely different data types, so inheritence was meaningless. There was common code and such subroutines had no inherent state, so such subroutines became a procedural, library function, not messages to an object.
Attribute driven, even in combination with other techniques, was a non starter as it would need a rules engine interpeting multiple boolean expressions. That would be heavy overengineering compared to 'if-elseif-elseif-else'.
And the 'evil' of the switch statements, in this case, would be that adding a new event type requires changing switch statements scattered around various places in the core event loop file. I'd rather not do that when core behaviour has not changed and a single interface definition ensures no function can be forgotten.
Overall, I used polymorphism to place site/event type specific code in one class file where it was more easily written and maintained. It was decided it was the best technique for the situation, not because I'm religious. Data modelling is not relevant here.
Matthew Greet
Choose Life. Choose a job. Choose a career. Choose a family. Choose a fucking big television, choose washing machines, cars, compact disc players and electrical tin openers. Choose good health, low cholesterol, and dental insurance. Choose fixed interest mortgage repayments. Choose a starter home. Choose your friends. Choose leisurewear and matching luggage. Choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting on that couch watching mind-numbing, spirit-crushing game shows, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pishing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourself. Choose your future. Choose life... But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got heroin?
- Mark Renton, Trainspotting.
|
Post #273,958
11/26/06 5:08:17 PM
11/26/06 5:16:36 PM
|
Domain things rarely divide nicely into "types"
If you found the one case in 50 where sub-typing actually works cleanly, then congratulations.
________________
oop.ismad.com
Edited by tablizer
Nov. 26, 2006, 05:16:36 PM EST
|
Post #274,004
11/26/06 11:16:55 PM
|
They divide about as neatly into types as the do into tables
[link|http://www.blackbagops.net|Black Bag Operations Log]
[link|http://www.objectiveclips.com|Artificial Intelligence]
[link|http://www.badpage.info/seaside/html|Scrutinizer]
|
Post #274,029
11/27/06 12:30:12 AM
|
Bull, hierarchies cannot do sets without duplication
________________
oop.ismad.com
|
Post #274,031
11/27/06 1:23:52 AM
|
I have no idea what you are talking about
but then I don't think you do either.
Apologies to Dave Letterman
[link|http://www.blackbagops.net|Black Bag Operations Log]
[link|http://www.objectiveclips.com|Artificial Intelligence]
[link|http://www.badpage.info/seaside/html|Scrutinizer]
|
Post #274,160
11/28/06 12:14:06 AM
|
Take sample sets and try to turn them into trees
....You will then see. (I know, polymorphism does not require hierarchies, but in practice usually ends up that way.)
________________
oop.ismad.com
|
Post #274,164
11/28/06 12:42:52 AM
11/28/06 12:43:09 AM
|
Why would I do that?
isSystemGood: sys
| goodSystems badSystems |
goodSystems := #( SunOS Linux)
badSystems := #('Windows NT' 'Windows 95')
(goodSystems includes: sys) ifTrue: [^true].
(badSystems includes: sys) ifTrue: [^false].
self error: 'Unknown System'.
[link|http://www.blackbagops.net|Black Bag Operations Log]
[link|http://www.objectiveclips.com|Artificial Intelligence]
[link|http://www.badpage.info/seaside/html|Scrutinizer]
|
Post #274,255
11/28/06 5:44:13 PM
|
Reinventing query languages in Smalltalk again?
\nSELECT OS_Name, IIF(osBase='UNIX','Good','Bad') AS Jugdement\nFROM OperatingSystems\n (Some dialects use WHEN...ELSE...END instead of IIF) ________________
oop.ismad.com
|
Post #274,265
11/28/06 7:19:27 PM
|
Smalltalk queries/collection operations predate SQL
by about 5 years I think.
Smalltalk collections respond to:
select: - provide filtered version of collection ie
#( 1 2 3 4 5 6 ) select: [:each | each isEven].
#(2 4 6)
detect: - first found
#( 1 2 3 4 5 6 ) detect: [:each | each > 3 and: [each isOdd]].
5
reject: - inverted select
#( 1 2 3 4 5 6 ) select: [:each | each isEven].
#(1 3 5)
collect: - used to derive a new collection from an existing one
#( 1 2 3 4 5 6 ) collect: [:each | each * 5].
#(5 10 15 20 25 30)
Nothing to reinvent, really. We were here first.
[link|http://www.blackbagops.net|Black Bag Operations Log]
[link|http://www.objectiveclips.com|Artificial Intelligence]
[link|http://www.badpage.info/seaside/html|Scrutinizer]
|
Post #274,309
11/29/06 1:57:56 AM
|
It does not predate OTHER relational languages
________________
oop.ismad.com
|
Post #274,313
11/29/06 4:01:51 AM
|
What are you NUTS?
Smalltalk?
seriously any of the *talk languages...
You are on Drugs.
-- [link|mailto:greg@gregfolkert.net|greg], [link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwetheyFreedom is not FREE. Yeah, but 10s of Trillions of US Dollars? SELECT * FROM scog WHERE ethics > 0;
0 rows returned.
|
Post #274,698
12/3/06 5:51:24 PM
|
First relational languages appeared in the early 70's
and earlier if you count Codd's math notation.
________________
oop.ismad.com
|
Post #274,707
12/3/06 7:15:56 PM
|
Smalltalk was 71
[link|http://www.levenez.com/lang/history.html#03|http://www.levenez.c...g/history.html#03]
Don't bother quoting Codd's math notation. Not implemented == not exists.
You may now put your pipe down.
|
Post #274,708
12/3/06 7:24:49 PM
12/3/06 7:28:35 PM
|
Some context...
Map, Filter, and Reduce are morphisms arising from mathematics. Likely that if you want to find the first use in programming languages, you'd probably find them in Lisp. But then Smalltalk was heavily influenced by Lisp (and Algol), so that wouldn't be surprising.
Map applies a function over a collection. Filter applies a predicate to a collection and returns a subset where the predicate is true. Reduce is a fold of a collection.
Guess I should also reuse my explanation of [link|http://z.iwethey.org/forums/render/content/show?contentid=247589|Higher Order Functions] in an earlier thread.
Edited by ChrisR
Dec. 3, 2006, 07:28:35 PM EST
|
