IS A vrs Contains A

Explanation of “IS A” rather than “contains A” (or "Has A")

Im going to make type BOX

Type Box
Field Size:int
EndType

And a type present

Type Present
Field Cost:Long ‘Rich Parents
EndType

Now my birthday gift "is a" box "containing a" present.

Type BirthDayGift extend Box
Field APresent:Present
EndType

Now I go to the post office and I pass my BirthDayGift to their Box weighing machine.

Function BoxWeighingMachine:int(ABOX:Box)
..
Return Weight
EndFunction

The man doesn’t say “That’s not a BOX, because it “IS A” box. it’s a box that contains a present
I go back the next day with a faulty good to return

Type FaultyGoodReturn Extends Box
Field FaultyGood:String
EndType

And again it is passed to the weighing machine, because Its still “A BOX”

@CS_TBL,
I posted it here as it wasnt really part of that thread

Isn't it really a matter of strong vs. weak associations?

If something "is a" then that represents a composition. For instance a triangle is a composition of points. If the Triangle is destroyed, so are it's points.

If something "contains a" that represents and aggregation. Were this the triangle from above, the points would still exist independantly if the triangle is destroyed because it is a stronger binding.

Yes but, the type cannot be 3 "Is A" things. If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. Because a triangle isnt a point

What the triangle is, "IS A" list of three points, so I could inherit from a type of "grouped" points, called shape for example. Then any function that requires a shape, could be passed a triangle directly, because a triangle, if inheretid from shape, "IS A" shape

Its not important if they exist or not. It more of a "If I asked bob to pass me a XXXX, and he passed me YYYY, are they the same. If I (As a function) wanted some nuts, but was passed a nut revel. Is that a sweet that contains a nut. Or is it a nut with some chocolate?

If I inheret Nut Revel from the base Nut, then I can passit directly to functions wanting nuts. Equaly if I wanted to inheret form type sweet, then I could pass the field of the nut to the nut functions, but not the whole revel

(Flame I posted this on request to explain what I ment when I said "IS A" as apposed to "Contains A")

Its my fun thing otm ;)

On your "Is A" explanation: it's typically the kind of explanation that hits the rocks here .. all c++ books I have (well, ok, 2 books :P) start talking about these realworld situations when they try to explain OO. To me this never worked, I prefer code-jargon, not talks about dishwashers and animals.. :P So, no matter how long I stare at your post office, it goes [-> o_O] and [O_o ->] :P (sorry :D)

I was trying to come up with some example code which works fine without any OO (that's what took so long), was too lazy to finish it.. I've more hobbies than just blitz'ing :P

meanwhile, this is an interesting read. http://www.geocities.com/tablizer/myths.htm
and
http://www.geocities.com/tablizer/oopbad.htm
and
http://www.softpanorama.org/SE/anti_oo.shtml

I had a talk with a coder (system, libraries, applications, c64 stuff, hardware, audio, everything) and he could come up with 1/0 reasons why inheritence is bad.. maybe I should just post a bit o' irc-log.. :P
Don't mind the language, he's a Czech, which means only half his words are bugfree, I think most ppl should be able to follow it.. with a little fantasy .. ^_^


ok, I have base class A
it's "visual" object,
usually having "x,y,color"
then I will do
B from A and 'B' will be image 'drawing' thing.
so, it autoamtically have x,y & color.

1. what happends, when 'B' don't need ANY color ? or colro is fixed ? Why it have 'color' attribute then ? (waste memory, break clean object attribs)

2. I have my 'own' system, which do something. I have 'myClass' and 'myClass2'. I want myClass2 to support 'image' - how ? I can't derive from '2' basic classes ! (the only lang can do it is c++ and it brings nmany problems). Delphi (pascal), c#, java , ... none of this langs support derive from 2 ancestors (he can argue only by interfaces, which are *NOT* deriving - even C++ can implement
interfaces on deriving layer - but jsut because yuou can have 2 paretnts - and as I say, no other lang is known to me :)

3. what happends, when I will add in MY object "rotation" - and later, in new version, author of original base class will also add "rotation" - to *ALL* objects -> it will conflict with my own declaration and program will stop work

4. what will happen, when multiple 'version' need to be used as DLL's ? This is not big problems for interpretting langauges, but for c/c++ like langs this is killer problem - all versions need to be EXACLY the same

5. if object needs 10 colors, you can't just use 'color cols[10]' because you need to fuck around with 'color' - many other part of system could reference 'color' -> another complication

6. with deriving, you have no control over usage of yourself - any1 can override methods, change things, ... -> in longer time terms (more ppl, bigger projects) -> problems [and some pubpic/private/... is *NOT* enough !)

7. sharing variables is very dumb - if you expect somethign to be nto change during 'some call' - you can't rely on that... and you have no control -> the bst way for deriving is to not share varaibles - but jsut methods (some programmers using derivating acknowledge this is to be the only good practive) -> you lost one of biggest advantages of deriving

------ ------ ------ ------


imagine you have 'file' class
it ahve methods like
read
write
you know, file is *SLOW*.
so, I will do
type cached_file Extends File;
and now I will show you, how easily inheritance goes to ass.
I defined some methods which 'enahce' file about 'cache'
eg,. you called "read"
it reads BLOCK
from 'base' class
and 'reads' from that 'cache'
so, both objects have 'read'
but
cached_file read reads jsut 'aray'
and if array is 'empty' then it calls
'read' of basic class (file)
everything works fine.
but there are 2 problems:
(big one)
let's say I will add NEW method to 'file' - eg. "search"
it searchs file and set position to 'some' specified place.
but I dodn't modify "cached_file"
so what happends ?
base class searchs & seek but 'cached_file' didn't update it's buffer.
so, if you use 'cached_file.find' (which you have from base class !)
your code no longer works.
another problem is,
if you use 'cached_stream' as "base" class.
and do
base.read
which METHOD will be called ?
cached_file.read
_or_
file.read
this is BIG problem./
this one can be solved - usually using 'virtual' methods (here you can see, it REQUIRE special implementaion frmo language !!!)
and first problem ?
can't be solved !
and this is the most pissed thing on deriving:
if you setup 'base' classes - you can't change them too much anymore......
you never know, how ppl use you.
so, if you are the only programmer, do not share anything, deriving could be acceptable options.
in any other ways, deriving failures for MANY reasons.


note that I can't really comment on inheritence, it's not my thing.. so these are his words, if someone reacts I'll redirect him to this thread and post the reply.. (can't BRL have something like inviting ppl, who don't need to buy a product to join here, for the sake of interesting'ness)

Some previous discussion here in my early Max days (not that I've learnt much since either).

I only used the real world example so that the code I posted would be smaller. As a real programming example here.

I have a class TLED. Which is a single colour shape to be drawn on the screen

Type TLED'A Shape, a Colour, and a Position 
				'-----------------------------------------------
Field IsItOn	:Int
Field Rotation	:Int 
Field TimeSinceChange	:Int 
Field Size	:Float
Field Shape	:TShape		  
Field Position	:TBiFloat 
Field Color	:TRGB	 
				'----------------------------------------------
Function Create:TLED (Position:TBiFloat,Size:Float,Color:TRGB,Shape:TShape,Rotation:Int = 0)
		
	Local Temp:TLED = New TLED.Allocate(Position,Size,Color,Shape,Rotation)
	Return Temp
		
End Function
				'----------------------------------------------
Method Allocate:TLED (Position:TBiFloat,Size:Float,Color:TRGB,Shape:TShape,Rotation:Int = 0)

	Self.TimeSinceChange	= 0
	Self.Shape					= Shape
	Self.Position					= Position.CopyCreate()
	Self.Color 					= Color
	Self.Size  					= Size
	Self.Rotation 				= Rotation
	Self.IsItOn					= False
	
End Method
				'----------------------------------------------
Method TurnOn ()				
		
	If Self.IsItOn <> True			
		Self.IsItOn = True		
		Self.TimeSinceChange = 0	
	EndIf	
	
End Method
				'----------------------------------------------
Method TurnOff ()
		
	If Self.IsItOn = True		
		Self.IsItOn = False
		Self.TimeSinceChange = 0
	EndIf
	
End Method
				'----------------------------------------------
Method Switch:Int ()		
		
	If Self.IsItOn = True
		Self.TurnOff
	Else 	
		Self.TurnOn
	EndIf 
		
	Return Self.IsItOn					
	
End Method
				'----------------------------------------------
Method ChangeColor (Color:TRGB)
	
	Self.Color	 = Color		
	
End Method
				'----------------------------------------------
Method ChangePosition (Position:TBiFloat)
	
	 Self.Position	= Position
	
End Method
				'----------------------------------------------
Method ChangeRotation (Rotation:Int)
	
	Self.Rotation = Rotation	
	
End Method
				'----------------------------------------------
Method RotateBy (Amount:Int)
 	
	Self.Rotation:+ Amount		
 	Self.Rotation:Mod 360		
	
End Method
				'----------------------------------------------
Method MoveByFloats (CX:Int,CY:Int)
		
	Self.Position.AddFloats(CX,CY)
		
End Method
				'----------------------------------------------
Method moveBy (Amount:TBiFloat)
		
	Self.Position.Add (Amount)
		
End Method
				'----------------------------------------------
Method Draw ()	
	
	SetOrigin			(Self.Position.CX*PaneSize.CX , Self.Position.CY*PaneSize.CY)
	SetRotation		(Self.Rotation)				
	SetScale 			(PaneSize.CX*Self.Size,PaneSize.CY*Self.Size)					
		
	If Self.IsItOn = True
		
		If Self.TimeSinceChange < 5			
			Self.TimeSinceChange:+ 1
			Local Dim:Float	 = Self.TimeSinceChange / 5.0	
			SetColor (Self.Color.red * Dim ,Self.Color.green * Dim , Self.Color.blue * Dim)
		
		Else 
			SetColor (Self.Color.red, Self.Color.green, Self.Color.blue)
		EndIf
	
	Else	
		SetColor(Self.Color.red / 5 , Self.Color.green / 5 , Self.Color.blue / 5)
	EndIf
		
	Self.Shape.Draw()

EndMethod
				'----------------------------------------------
Method Resize(Multi:Float)
		
	Self.Size:*Multi
		
End Method
				'----------------------------------------------
EndType

OK so with this object I want to make a number display, now a number display "Contains" TLED. Its not an "Is A" realationship, at best its an "Are some" realationship so the TLEDs need to be Fields

Type TLedNumber'A calulator number
				'----------------------------------------------
Const LedTop				:Int	 	= 0 
Const LedTopRight		:Int	 	= 1 
Const LedBottomRight	:Int		= 2 
Const LedBottom			:Int	 	= 3 
Const LedBottomLeft		:Int		= 4 
Const LedTopLeft			:Int		= 5
Const LedMiddle			:Int		= 6 
				'----------------------------------------------
Global Shape:TShape = TLedNumber.CreateShape () 	
Global LEDLogicArray:Int[][] = TLedNumber.CreateLedLogicArray() 	
				'----------------------------------------------
Field Number	:Int 
Field LEDArray:TLED[7] 	
Field Position	:TBiFloat
Field Color		:TRGB
Field Size			:Float
				'----------------------------------------------
Function CreateLedLogicArray:Int[][] () 
		
	Local Temp:Int[][]= [ 	[1 , 0 , 1 , 1 , 0 , 1 , 1 , 1 , 1 , 1]..
			 						, 	[1 , 1 , 1 , 1 , 1 , 0 , 0 , 1 , 1 , 1]..
									, 	[1 , 1 , 0 , 1 , 1 , 1 , 1 , 1 , 1 , 1]..
									, 	[1 , 0 , 1 , 1 , 0 , 1 , 1 , 0 , 1 , 1]..
									, 	[1 , 0 , 1 , 0 , 0 , 0 , 1 , 0 , 1 , 0]..
									, 	[1 , 0 , 0 , 0 , 1 , 1 , 1 , 0 , 1 , 1]..
									, 	[0 , 0 , 1 , 1 , 1 , 1 , 1 , 0 , 1 , 1] ]
		
	Return Temp
		
End Function
				'----------------------------------------------
Function CreateShape:TShape() 
		
	Local Temp:TShape = New TShape.CreateFromArray..
	([0.0, 4.0, 1.0, 2.0, 1.0, -2.0, 0.0 ,-4.0, -1.0, -2.0, -1.0, 2.0]) 
		
	Return Temp
		
End Function
				'----------------------------------------------
Function Create:TLedNumber (Size:Float=1,Color:TRGB=Null,Position:TBiFloat=Null)
		
	Local Temp:TLedNumber = New TLedNumber.Allocate(Size,Color,Position)
	Return Temp
		
End Function
				'----------------------------------------------
Method Allocate:TLedNumber (Size:Float=1,Color:TRGB=Null,Position:TBiFloat=Null)
	
	Self.Number = 0
	Self.Size = Size
			
	If Color
		Self.Color = Color
	Else
		Self.Color = TRGB.Create(0,255,0)
	EndIf
				
	If Position
		Self.Position = Position
	Else
		Self.Position = TBiFloat.Create (100,100)
	End If
			
	For Local Cell:Int = 0 To 6
		Self.LEDArray[Cell] = TLED.Create (Self.Position,Self.Size,Self.Color,Self.Shape)
	Next
	
	Self.PositionCells 
	Self.SetNumber (Self.Number)
		
EndMethod	
	'----------------------------------------------
Method SetNumber(Number:Int)
	
	Self.Number=Number						
		
	For Local Cell:Int = LedTop To LedMiddle				
		If Self.LEDLogicArray[Cell][Number] = 1
			Self.LEDArray[Cell].TurnOn()		
		Else						
			Self.LEDArray[Cell].TurnOff()		
		EndIf
	Next	

End Method
				'----------------------------------------------
Method PositionCells()

	'	LedTop
	Self.LEDArray[LedTop].ChangeRotation (90) 
	Self.LEDArray[LedTop].MoveByFloats(0,-8)
	'	LedTopRight
	Self.LEDArray[LedTopRight].ChangeRotation (0) 
	Self.LEDArray[LedTopRight].MoveByFloats(4,-4)
	'	LedBottomRight
	Self.LEDArray[LedBottomRight].ChangeRotation (0) 
	Self.LEDArray[LedBottomRight].MoveByFloats(4,4) 
	'	LedBottom
	Self.LEDArray[LedBottom].ChangeRotation (90) 
	Self.LEDArray[LedBottom].MoveByFloats(0,8) 
	'	LedBottomLeft 
	Self.LEDArray[LedBottomLeft].ChangeRotation (0) 
	Self.LEDArray[LedBottomLeft].MoveByFloats(-4,4)  
	'	LedTopLeft
	Self.LEDArray[LedTopLeft].ChangeRotation (0) 
	Self.LEDArray[LedTopLeft].MoveByFloats(-4,-4)  
	'	LedMiddle
	Self.LEDArray[LedMiddle].ChangeRotation (90) 
	'LedArray[LedMiddle].MoveBy ( 0,0)
		
End Method 
				'----------------------------------------------
Method Draw()
	
	For Local Cell:Int = LedTop To LedMiddle 
		Self.LEDArray[Cell].Draw		 		
	Next
		
End Method
				'----------------------------------------------
Method moveBy (Amount:TBiFloat) 
		
	Self.Position.Add(Amount) 
	For Local Cell:Int = LedTop To LedMiddle 
		Self.LEDArray[Cell].moveBy(Amount) 
	Next
			
End Method
				'----------------------------------------------
Method MoveByFloat (CX:Int,CY:Int)
		
	Self.Position.AddFloats(CX,CY)
	For Local Cell:Int = LedTop To LedMiddle
		Self.LEDArray[Cell].MoveByFloats(CX,CY)
	Next
		
End Method
				'----------------------------------------------
Method SetPosition (Amount:TBiFloat)
		
	Self.Position = Amount
				
End Method
	
End Type

As you can see I need to provide a draw routine for the number, which fair enough just call the TLED draw
What I also have is "Aliens","Mothership","PlayerUnit" etc
Now each of these is also made of an TLED, which again I could just put as a field of the type. However I have said that the AlienLED for example, IS an LED.

Type TLEDAlien Extends TLED
				'---------------------------------------------
	Global AlienShape:TShape	= TLEDAlien.CreateShape ()
				'---------------------------------------------
	Method Create:TLEDAlien (Position:TBiFloat=Null,Size:Float=1,Color:TRGB=Null,Shape:TShape=Null,Rotation:Int=0)
		Super.Create (Position,Size,Color,Self.AlienShape,Rotation)
		
		Return Self
	End Method
				'---------------------------------------------
	Function CreateShape:TShape ()
			
		Local MyShape:TShape=..
		New TShape.CreateFromArray	([-2.5,0.5,-1.5,1.5,-1.5,-3.5,-2.5,-3.5])
		MyShape.NextPolyArray		([2.5,0.5,1.5,1.5,1.5,-3.5,2.5,-3.5])
		MyShape.NextPolyArray		([-1.5,-2.5,-0.5,-2.5,-0.5,-3.5,-1.5,-3.5])
		MyShape.NextPolyArray		([1.5,-2.5,0.5,-2.5,0.5,-3.5,1.5,-3.5])
		MyShape.NextPolyArray		([-.5,.5,.5,.5,.5,-.5,-.5,-.5])
		MyShape.NextPolyArray		([-1.5,1.5,1.5,1.5,1.5,0.5,-1.5,0.5])
		MyShape.NextPolyArray		([-1.5,-1.5,1.5,-1.5,1.5,-0.5,-1.5,-0.5])
		MyShape.Resize(New TBiFloat.Create(2,2))		
		Return MyShape
	End Function
End Type

What Im am doing is defineing the most basic things LEDs need, and then inhereted these to make each of the subsequent types. As you can see I dont have to worry about all that changecolour or rotation crap, because the TLEDAlien already has them (from TLED), I could easyerly make it a field, and then either write draw calls that call the fields draw, or call the fields draw directly. BUT TLedAlien.draw and TLed.Draw, are the same routine, so no extra work there

Your Points

1) If B doesnt need any colour, then you shouldnt try and inheret from a class that has colour. (This is a planing problem, not an inherent problem with Inhereting)

2) Type A
Type b extens A
Type c extends B

3) a) they are my base objects, so Iam the author, and I dont do that (well not very often)
b) Unless the rotation method is really stupidly done, you can just override it

4) Dont know. I wouldnt know how to do that in any languge.
But my understanding is that its the interface of the object that is important, and that has no relation to inheriting or not. Its surly, (If a problem at all), a problem about compilation

5) I have no idea what hes trying to say? If an object needed 10 colours, it needs 10 colours. (I think this was an argumnet used against useing types at all, rather than an argument against inheriting)

6) Errr and, thats not an arugument against you useing inhereting, is againt letting anyone else inhereting your stuff.

7) Is that about "Unions" cos it is totaly irrelivent to inhereting. Again I think that was an argument against types full stop.

And that entire monologue. He just need to learn how to use super. The entire monolouge is infact againt overriding in inhereted classes, and not inhereting in of itself

EDIT: In fact after reading you post again, and flash scanning the links, I think that your stance is against OOP, and not against inhereting.

his reply and his multiple typos ^_^ :


>1) If B doesnt need any colour, then you shouldnt try and inheret from
>a class that has colour. (This is a planing problem, not an inherent
>problem with Inhereting)
I am working and I was on various projects. From smaller to bigger ones
(100K+lines - tenths MB's
of source coud). I never saw system (design) where was possible to
create 'clean' design, just
because you fall down into huge tree structures. Deriving is always
about form of compromise.
You can't easily add 'fields per fields' and 'method per method' in tree
of classes.



>2) Type A
>Type b extens A
>Type c extends B
Don't work - you need "Type XX extends B,my_own". As I say, the only
lang (from mainstream) who
support multiple ancestor I know is C++, where it btings many problem in
imp[lementation
(VTBL offest, moved 'this' accross method calls, multiple method bodies
across classes, ...)



>3) a) they are my base objects, so Iam the author, and I dont do that
>(well not very option)
>b) Unless the rotation method is really stupidly doen, you can just
>override it
Sure, I can override, but if someone extend MY class - it could count
with ORIGINAL 'rotation'.
This is really common problem, and if you know a bit C# versioning, you
can check how deep
this problemis in real projects. I don't know other lang than C# who
solves this problem
generally. And I agree - (a) is not a option.



>4) Dont know. I wouldnt know how to do that in any languge.
>But my understanding is that its the interface of the object that
>is inportant, and that has no relation to inheriting or not. Its
>surly, (If a problem at all), a problem about compilation
There is a implementation layer problem. Generally only byte-code and
interpreted langs
could solve the problem. In C/C++/... and other 'compiled' languages you
are strating
having troubles with field aligemnt, method offsets, etc. (I mean 'real'
ones).



>5) I have no idea what hes trying to say? If an object needed 10
>colours, it needs 10 colours. (I think this was an argumnet used
>against useing types at all, rather than an argument against >inheriting)
I want to say, that any 'ancestor' or 'other' objects could assume I am
working with
field 'Color' - but I am not using it. I have 'Colors[10]' array. So, I
have to
use 'Color' and 'Color[9]' which complicates code a bit (note: this is
from real projects,
where because of deriving was ppl forced to create various 'stubs' just
to make other
classea around happy with presumtions).



>6) Errr and, thats not an arugument against you useing inhereting, is
againt
>letting anyone else inhereting your stuff.
That's a BIG argument. As author of some 'stuff' I need control usage of it.
Many problems are caused by non-planned features/behaviours, which are not
initially planned. If other starts using them as 'features' - you have
to accept it
or break the system. Deriving don't give you control about methods -
that they will
be called as YOU expect. Eg. if I will do method, which is allowed to
derive, but
you define, user have to call base one, you have *NO* control, it will
work that way. So, it is not forcing ppl to use only for things you
designed system for, but force them to use WAY yuo expected/design.



>7) Is that about "Unions" cos it is totaly irrelivent to inhereting.
>?Again
>I think that was an argument against types full stop.
This is. Inheriting typically says facts about speed, usability etc. It
holds only
if you share variables. As I say, many OOP programmer (generally) don't
use sharing
variables (for that reasons). It's again about control. You can assume,
that some
varaible is CONSTANT during some algorihm. If you call user
event/callback somewhere
inside, variable may be changed. our algo can goes to hell. Sure - you
don't need
to share variables and use 'methods' - where you HAVE control over own
internal state,
but then you loose one of most nicest thing on deriving - speed &
simplicty. With sharing
methods only, you are more near compoennt based programming.



There are several way, which way one can write code. There are many
articles about OOP, COP,
procedural etc. I don't know any mainstream lang, which implements OOP
(generally) way, I would
like & use (and company here). In most cases, well written procedural
programming could be
faster, better & more ready for futre than typical OOP.


With OOP you have no control over your own usage. If tenths various ppl
uses your classes,
you need to have control. Not about 'where' and 'for' they use you, but
if they use you
as YOU EXPECT. THat's why where are many things like COM, COM+, DCOM,
CORBA and many many
other system, which are mainly about deffinig COMUNICATION - rules. Not
just giving your
own internal state into hands of others.


I saw too much projects in state, where no-one was really abble to
change some of base
classes. Because if you will do that - other will stop work.


And yes, I am "typical OOP" sceptic and I don't like it :) As someone,
who talk with CS_TBL
about these things, I tried to explain him another ways how to work. I
fyou are intereating,
you could take a look at some other ppl with similar meanign like me.



Personal note: he tries to do so since 1999 orso, I just mess around with code like Dory swims ... "just keep swimmin' just keep swimmin' just keep swimmin' swimmin' swimmin' what do we do we swim"
Whatever I discovered have been my own discoveries, just by swimming and not listening to anyone ^_^

There not typos. Typos are when you know what letter to type, but you hit the wrong one. What I have is a problem with knowing what letter to hit. ;)

a) I dissagree here totaly. (Or rather I agree totaly). I dont think this is OOP or inheretence or the like problem, this is a "Thats the way it is" problem. But again, I feel Im defending inhereting, and your attacking deriving.

b) I agree, we do need multiple inhereting

c) Here is were we diverge as to what we are as programmers. Im a lone programmer. No one but me as access to my types. (You maybe right in a big organisation)

d) Again, cannot see relevence to problem.

e) Ahh, this is the same as the second codebox, simply dont inheret in this situation. This tho is not a problem with inhereting, just an indicator that you should derive

f) Ok I see your point. But its a point for a stronger keyword "Final" than against inhereting

g) Ahh, yes ok is see what you mean. But isnt that a problem in any language that allows me to pass a pointer to the variable? (Or to the type)

If this was a disscussion about to use object or not, then I would hardly mention inhereting at all. It isnt about that. Its a, "If you are useing OOP", should you use inhereting

Whislt your points might be hard to rebuke in the first argument, they are not relevent if you do concider that is a disscuion for "after" you have desided to oop.

Could you elaborate on that? I would like to know how you generaly would "setup" a program.
Using types with just fields, global functions and no global variables?
I know one can use different aproaches to a programming-enviroment, and one is not necessarialy better than the other?
Please give me your view on that.

his reply:


>There not typos. Typos are when you know what letter to type, but you
>hit the wrong one. What I have is a problem with knowing what letter to
>hit. ;)
I do both :) Sometimes I don't know exact spelling even @ my native
lang, which is pretty "crazy"...


>a) I dissagree here totaly. (Or rather I agree totaly). I dont think
>this is OOP or inheretence or the like problem, this is a "Thats the
>way it is" problem. But again, I feel Im defending inhereting, and your
>attacking deriving.
Basically yes. OOP is 'geneal' term, and it was used by me and CS in
'deriving' context. I think it is most used (or most seen meaning).
Generally, OOP could be reprezsnted by:


- procedural programming
- asm
- inheriting and tree of classes
- components
....


Many other things. Sure, orthodox "OOP" ppl will completely disagree
here (talking about security/encasing of members, ...). But generally
OOP could mean anything. Its' (at my opinion) way of coding, rather some
concrete language/syntax/...


I hate deriving. On the other side, I approve some other OOP ways. On
the other side - I prefer procedural OOP rather pure deriving & tree of
classes.


>b) I agree, we do need multiple inhereting
Never say this ahead of orthodox OOP ppl :) They could kill you for
that. Multiple inheriting brings many many implementation problems. If
you know a bit C++ compilers (generated code, how it works), you know,
how complicated are 'virtual' members, virtual ancestor (versus
non-virtual ones). You could check typical C++ streams - ios etc. Their
implementation (from deriving POV) really SUX. And generated code is
also much more complicated, than using 'standard' ancestor - these
thigns need to use "virtual ancestor" (this is C++ terminology, but it
means, there is "more" ways how to derive)



>c) Here is were we diverge as to what we are as programmers. Im a lone
>programmer. No one but me as access to my types. (You maybe right in a
>big organisation)
Sure. What is good for one, doesn't need to be good for others. But... I
personally think, that even for one, another ways of doing "OOP" could
save many lines of code -> time.



>d) Again, cannot see relevence to problem.
You will feel the problem, when your system will support 3D and you will
have to do millions operations per seconds. Until you have just hundreds
sprites on screen, you don't feel difference. When you will start doing
transformations, ... in more complicated scene, you may start feel how
things are implemented. I wanted to say, that at certain point you are
starting feel with "compiler" (interpreter...). There are thing, which
can't be processed simpler/easier.



>e) Ahh, this is the same as the second codebox, simply dont inheret in
>this situation. This tho is not a problem with inhereting, just an
>indicator that you should derive
If I will not inherit, I can't use other things. And it sux. While you
inherit, you can't "select" what you wish to inherit, what to inherit
but process by yourself (but let ancestor freely use), etc. And it is
the point. You are pretty limited. You have no control/selection. That's
why nearly every 'deriving' based system tracks many unneeded things. Or
because you don't need 1 feature, you will not derive and lost 10 other ?


>f) Ok I see your point. But its a point for a stronger keyword "Final"
>than against inhereting
Not really. Final doesnt' help. Try to think about few "use cases". And
if you started using 'final' - you break inheriting principles. With
inheriting - you could use final everywhere then :) No really, really
few langs could solve this issue, even not using inheriting. With
inheriting, this issue just raise 10x more.


>g) Ahh, yes ok is see what you mean. But isnt that a problem in any
>language that allows me to pass a pointer to the variable? (Or to the
>type)
You don't need pointer to raise that problem. But allowing 'remember'
instance (store pointer) also raise this problem. Like previous - with
inheritance this issue is 10x raised. Nevertheless, many of inheriting
troubles could be found in other langs - even they don't have inheriting
by itselfs.


>If this was a disscussion about to use object or not, then I would
>hardly mention inhereting at all. It isnt about that. Its a, "If you
>are useing OOP", should you use inhereting
As I explained, I used OOP in most used term - inheriting. When OOP was
"discovered", one of most propagated advantages *IS* inheriting. Check
any book for Java, C#, C++, ... any OOP-like lang (I used like, because
none of these lang is *really* OOP in right word of meaning) promote
inheriting. One of "most used" features. So, that's why me (and also
many others) use OOP very often as synonym for inheriting.



>Whislt your points might be hard to rebuke in the first argument, they
>are not relevent if you do concider that is a disscuion for "after" you
>have desided to oop.
What I discussed with CS wan't "procedural OOP" but "component based
programming" - which is pretty different in designing/thinking from
inheriting-OOP. There is not much languages, which creates good
enviroment for COP. There are few things, like COM/COM+/DCOM, which are
hacked "C" basically. Few better (CORBA, ...) but none really COP. It's
like saying C++ (or Blitz) to be real OOP. Both langs are far from being
OOP. If so, you will end up in languages like LIST



and


>Could you elaborate on that? I would like to know how you generaly
>would "setup" a program.
>Using types with just fields, global functions and no global variables?
>I know one can use different aproaches to a programming-enviroment, and
>one is not necessarialy better than the other?
>Please give me your view on that.
As I explained, it wasn't really against OOP - but against deriving
based OOP. Every language I know (even strict OOP) have 'global'
variable. At least instance of process itselfs. It have to work that
way, until OS will be completly OOP. And still you will end up in
global/static instances, because you have just 1 CPU, etc.


My personal view on OOP (deriving based) is very similar to ppl, which
wrote articles I posted somewhere above. There are many common "lies"
regarding OOP.


I am personally into clean component worlds. Components is not component
in view of class (eg. TComponent in Delphi and similar enviroments), but
it defines something, what could internally contain anything (you don't
care) and you communicate throw known interfaces. It it not just list of
methods, like interface in most component OOP (COM, java, C#...). It
much more. It setup of rules, when/what/who/how. Mapping of methods and
objects is 'internal' thing of given component, and you have no way how
to review that. You don't need to.


Components allow mass code-reusing, without poke along history rock. You
can easily implement caching/streams (somewhere above I posted small
use-case). Many ppl call that aspect oriented programming
(http://aosd.net) but this is just a small part of it.


Also, I don't see objects as 'this' instance. I see objects as tree
structure itself (you could have 3 'this').


There are many things I see different from many other ppl. It's another
story, and if we want to seriously discuss that, it could be very long
thread.


To be open, there is not yet any language, which fit all me needs.
That's one of reasons I wrote 'hack' for C++, which creates something
like COM+, but pretty different way. But still it's far from ideal
state. So, in the way, I started in free time doing own small project,
which can prove or destroy what I am saying. Many ppl I have talekd
about that goes with me, because these problem I am talking about are
pretty common.


So, there is really many things I see differently, nut just deriving.
But deriving it 'top pissed feature' in OOP I think. I there will be
some vote about "Worst OOP programming way", I will put my 10 cents for
deriving, as it is implemented in most languages (delphi, blitz, c#,
java....).

Why not?

No. That's what you have your composite pattern for. So that you don't have to care whether you component is a single object, or a collection of objects.

That sounds much too convoluted, and unmaintainable IMHO. No offense.

Yeah. It's always interesting to read people trying to bash something they don't understand.

How else would you know WHICH color it is?

Interfaces and/or composite objects. How exactly is situation dependant.

Lack of functioning version control is not a problem specific to OOP.

DLL Hell. Oddly, this is actually a symptom of not using OOP. If you have a well defined Interface, than the program shouldn't care less how the underlying implementation. If it does, your implementation is not OO.

That's just rediculous. What would an object need 10 arbitrary colors for?

But Final is. Besides which, since your object is ofcourse encapsulated, it doesn't matter whether someone else extends it.

Because having the ability to cause spectacular random concurrent access violation crashes on multiple Core systems - is definatelky an advantage. Right? I mean end users really enjoy programs crashing for no real reason at all.

While I'm sure your friend is quite the talented programmer, he obviously has not understood the purpose of Object Orientation. The purpose of OO is Abstraction and Encapsulation. Inheritance is a powerfull tool. I'd like to see someone write an easy to use composite pattern model without it. Ugh.

Why not?

Dont be so enigmatic in your replies. If I say it cannot, and you think it can, then post it, so then I know it can as well

"IS A" = extened
"Contains A" = Has the fields
I dont know how to have more than one extends.

Type TType extends a,b,c maybe?

No. That's what you have your composite pattern for. So that you don't have to care whether you component is a single object, or a collection of objects.

Well your just wrong here. If you wanted to say.

Yes, H&K thats right, but what you would do is use a composite pattern. So that you don't have to care whether you component is a single object, or a collection of objects.

Then you would be right. But "If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. is correct.

Fair enough on the revel example. It really needs diagrams (I wasnt saying have both, I was saying pick one)

..hmmm - more oo arguments - seems people are more
obsessed with writing oo code that fits some pre-defined
"perfect concept" - than actually using it as a tool..
Dont get me wrong, there are of course good and bad
ways of going about doing things, but i think it needs to
looked at within a specific context..not jst some generic
this is good that is bad approach...

ISa

sorry..i know thats not really what your talking about..
but all im saying is that sometimes its good to mix and
match oop with conventional procedural techniques to
avoid a tonne of cumbersome wrapping...

im not convinced having classes for everything is a good
idea..a collection of points forming tris, might be better
stored as an array of floats..not a collection of points..

heh, anyway - thats jst my pointless thinkings on this ;)

Yet another reply... let's keep 'em coming ^_^


>3. what happends, when I will add in MY object "rotation" - and later,
>in new version, author of original base class will also add "rotation"
>- to *ALL* objects -> it will conflict with my own declaration and
>program will stop work
>Lack of functioning version control is not a problem specific to OOP.
In deriving based OOP this problem is much bigger than in anything else.



>4. what will happen, when multiple 'version' need to be used as DLL's ?
>DLL Hell. Oddly, this is actually a symptom of not using OOP. If you
>have a well defined Interface, than the program shouldn't care less how
>the underlying implementation. If it does, your implementation is not >OO.
Same like [3]


>5. if object needs 10 colors, you can't just use 'color cols[10]'
>because you need to fuck around with 'color' - many other part of
>system could reference 'color' -> another complication
>That's just rediculous. What would an object need 10 arbitrary colors >for?
Why you should expect anything, while base class ? In typical deriving
base OOP you have to do that -> one of reasons, why system is bas all
(meaning deriving).


>6. with deriving, you have no control over usage of yourself - any1 can
>override methods, change things, ... -> in longer time terms (more ppl,
>bigger projects) -> problems [and some pubpic/private/... is *NOT*
>enough !)
>But Final is. Besides which, since your object is ofcourse
>encapsulated, it doesn't matter whether someone else extends it.
It's like [5]. If you started using finals, why someone should derive
then ? Class with finals is more like interface -> ot';s mroe object
assembly, than deriving. In more similar examples, you can see, how
deriving failures - whole "idea" do that. You have to use final, to
prevent troubles (or explicitly use "friend" class names), you have to
ask "why someone need something" - because you designed system "some
way" and any other is ....


>you lost one of biggest advantages of deriving
>Because having the ability to cause spectacular random concurrent
>access violation crashes on multiple Core systems - is definatelky an
>advantage. Right? I mean end users really enjoy programs crashing for
>no real reason at all.
>
>While I'm sure your friend is quite the talented programmer, he
>obviously has not understood the purpose of Object Orientation. The
>purpose of OO is Abstraction and Encapsulation. Inheritance is a
>powerfull tool. I'd like to see someone write an easy to use composite
>pattern model without it. Ugh.


Just note: as I allready explained, OOP was used mainly in menaing of
deriving based OOP (most used way @ (at least this) world).


I don't know if I am talented programmer, but regarding this topic, I
already wrote few langs (including typical OOP-deriving based, from
interpreted up to real compiled), wrote hacks to other compilers, etc.
So, I think, I have some experience. I can't judge how big unfortunately
:) Whole deriving based OOP tends into troubles, you named (as argument
for d-OOP side) few of them. This is like alternate and allopath
medicine (easter/western). If you have some problem, western medicine,
in most cases, will cure tokens. On the other side, if you have pain in
legs, why someone should cure liver ? (jsut example :) Small count (at
least here) from allopath medicine tries to find illness origin. Similar
with deriving OOP. There is many problems (I am not saying, other system
don't have any), like we was talking about. Look at modern lags. Many
ppl should learn form chinese-like thinking in medicine. If there is
some pain, it's not (in most cases) best way to minimize it's show. Like
- OOP tends to have history rock problems - like:


1. member names (adding later on childs/parents/...)
2. impossibility to change anything, coz you risc system failuring
3. redundant members, which are used in SOME 'childs' and ancestor CAN
work this them
...


So, instead of trying to minimize this problem (on lang/design layer),
MS (and others) found solution: HUGE versioning system, which could
solve all these illness. But it doesn't mean, you have better system.
You just have way, how to cut down impact of that.


Similar to other things.


Sure, you can find similar problems in other OOP too, or non-OOP. But in
deriving OOP, all problems, we were talking about are biggest ones.


This thread have one small problem: if discussing ppl never meet
deriving OOP based project, in size (at least) ~tenths of thousands
lines with hundreds classes, they will probably never see these points.
At certain point, I belive every1 will see.


I guess you know refactoring. It's another 'nice' thing, how to make
results "better" while keeping system bad :) Refactoring could also
repair many things, but it just minimizes fallenness... It doesn't cure.


Like CS. Until he wrote code (1 file) up to 5K lines, he was "lazy" to
do many things, which you should expect to be in code. At certain point,
he found, that it's not possible to remember everything. He wishes to
reuse some portions of code... He found, simulating 'instances' throw
array wasn't soo clever as it looks in the beginning :) That's why he
stared this thread.


But before ? He would never belive you or me :)


Or me, when I was starting programming (asm @ C64 - nice machine :) I
was same like he was. It was long time ago..


At certain point I changed my mind. And srated writing code to be
'readable' - I found my brain is to weak to remember all in ASM files,
which had 20.000 lines... Same happends later with deriving based OOP. I
love it :) Really. Until first big project grows, grows, more and more
ppl have to work, ... Even I was 'more open' at that time already, as
far as we reach point of no return, I have preferred deriving based OOP.
It becomes slowly.... It happens -8 years ago if I remember well.


So, that's why these kind of threads are long and both sides need to
have mind open to "different" things - if not, we will cycle around few
points, like happen here.


------------------- -------------------
Note: the instances in an array is long ago, pre-Blitzplus even. The problem I have is that I'm usually the user of my own tools, so because of creative reasons I tend to rush things in order to be able to use it yesterday. And since those tools are unique in some way, I can't use alternatives. Since B+ I hid my stuff privately in banks, and since BMax I hide them in types.

Question:
So no matter how well I think Ive programed, and no matter how well namedspaced everything is, I will reach a point were I will wish that I hadnt Derived any classes at all?

Retoric:
Whats the alternitive?

No classes, well thats just stupid, and I am not going to believe that ever.

One seperate class for each variable structure I want? This would be more work, and to be honest I again wont do it. If a want a variable structue with one more variable than a structure I already have, then I am definatly either extending the first structure or "field"ing it.

One Giant calss with redundent variables, capible of being all my variable structures? Well thats spectrum basic, in reality no types at all.

I apprechiate all your strong opinions about the problems of oop, and extending in particular, but I think you are simply highlighting pitfalls that can then be avoided, as apposed to showing an unpassable chasim in the road.

I also think that there are alternative solutions to programing that dont require oop, but to say that because oop isnt perfect you shoudnt use it, is illadvised.

On the westen/easten medicine thing, the west has always tried to fix the body, whilst the east has always tried to keep the body from needing fixing. In the end a best system would include them both? (Bear in mind I have not been saying you "should" inheret all the time, yet you have been saying you should never, and you see that the analogy supports my stance)

Have a go at the retoric if you want, but the question is what needs anwsering. (I got a bit carried away, and the question seemed to take second place, but it isnt)