Waarom VB geen OO-taal is.

[pkouwer]

Ik hoorde laatst collega's roepen dat VB geen echte O-taal is en bv C++ wel. Nu weet ik er zelf te weinig vanaf om daarover te oordelen, maar op welke basis is een taal wel of geen OO-taal. Deze vraag is puur interesse: wil het gewoon weten )

[pjonk]

Je kan misschien beter zeggen dat VB geen complete OO taal is, want je kunt wel degelijk classes gebruiken alleen dan in beperkte vorm.

Het mist een aantal zaken zoals inheritance, polymorphism, operator overloading etc.

[Verwijderd]

Kortom je hebt geen idee wat OO is en nu moeten wij uitleggen waarom vb het vooral niet is.. ermmzz klinkt zinnig? Zou je niet beter gewoon even op kunnen zoeken wat OO globlaal inhoud en daaruit je eigen conclusies trekken?

[Verwijderd]

Zekers dat VB wel een OO-taaltje is...
En nu helemaal in de .NET omgeving van M$

Ik ben zelf al 6 jaar beroeps VB-er dus heb alle versies vanaf VB3 wel meegemaakt en nu zijn ook de oudere versies niet helemaal OO, maar de laatste versies zeker wel.

[mbravenboer]

Goh, waarom wil al die wannabe taaltjes toch zo graag ook OO zijn .
[topic=531987/1/25]
(niet happen, grapje ).

Verder zou ik VB .NET toch wel even los willen zien van het oude VB. Iemand die zegt dat VB .NET niet OO is, zegt imho dat C# ook niet OO is. Iemand die zegt dat C# niet OO is, kan beter garnalen gaan pellen.

Verder: ach... wat is OO? Horen interfaces bij OO? Hoort operator overloading bij OO?

Verder: ach... is goede OO ondersteuning nu echt het summum voor een taal?

[whoami]

VB is geen OO taal, VB.NET is dat wel.

Waarom is VB geen OO - taal?

Om object oriënted te zijn, moet een taal aan een aantal eigenschappen voldoen:

- abstraction
- data hiding, data encapsulation
- inheritance
- polymorphisme

Aangezien inheritance en polymorphisme niet mogelijk zijn in VB, is VB geen OO-taal.

[whoami]

Op zondag 23 juni 2002 17:24 schreef Gracioso het volgende:
Zekers dat VB wel een OO-taaltje is...
En nu helemaal in de .NET omgeving van M$

Ik ben zelf al 6 jaar beroeps VB-er dus heb alle versies vanaf VB3 wel meegemaakt en nu zijn ook de oudere versies niet helemaal OO, maar de laatste versies zeker wel.

Kun je dat ook even onderbouwen?

[mbravenboer]

Dit is trouwens wel een aardige presentatie over VB .NET, waar veel typische OO functionaliteit ter sprake komt:

http://www.microsoft.com/usa/presentations/DEVT1-99wbhNew.ppt

[Verwijderd]

VB is dan wel object oriented voor een groot deel, de meeste zaken zijn het nog niet.

Bovendien ontbreken een aantal belangrijke kenmerken van een OO taal, zoals (multiple) inheritance, friend functies enzoverder.

VB heeft bovendien een enorm slecht memory management, waardoor het creeëren van objecten soms niet mogelijk is.

VB is idd de naam OO niet waard. (ik dacht dat Smalltalk enorm OO was (variablen die signals emitten en ontvangen))

[mbravenboer]

Timtitanium: Bovendien ontbreken een aantal belangrijke kenmerken van een OO taal, zoals (multiple) inheritance, friend functies enzoverder.

Hier komt mijn vraag weer naar voren: wat is een OO-taal? Er is geen vaste definitie van wat een OO-taal aan functionaliteit zou moeten hebben en er is in ieder geval geen overeenstemming.

Multiple inheritance (van implementatie) is bijvoorbeeld niet aanwezig in C# en Java, wat beide toch wel de moderne OO talen zijn. Naar friends kan je ook lang zoeken in beide talen. In ieder geval vonden de makers van deze talen dus kennelijk dat dit geen belangrijke kenmerken van OO-talen zijn .

[whoami]

friend functies vind ik inderdaad geen kenmerk van een OO - taal...

De meeste mensen zijn er het toch wel over eens, dat de kenmerken van een OO taal:
- data encapsulation / data hiding
- data abstraction
- inheritance
- polymorphisme

zijn.

[Verwijderd]

C++ = ook niet 100% OO.. . .

[Aaargh!]

Op zondag 23 juni 2002 22:37 schreef whoami het volgende:
friend functies vind ik inderdaad geen kenmerk van een OO - taal...

Sterker nog, het juist erg niet-OO, je omzeilt nl. de encapsulation

Op maandag 24 juni 2002 02:18 schreef Skizmo het volgende:
C++ = ook niet 100% OO.. . .

C++ is idd een hybride taal

[.oisyn]

Op maandag 24 juni 2002 02:18 schreef Skizmo het volgende:
C++ = ook niet 100% OO.. . .

C++ bevat wel 100% van de OO mogelijkheden

[mbravenboer]

.oisyn: C++ bevat wel 100% van de OO mogelijkheden

Das een gevaarlijke uitspraak . Wat zijn OO mogelijkheden? Support C++ bijvoorbeeld double-dispatch/multi-methods? (das een retorische vraag ).

Is het domein van OO mogelijkheden uberhaupt wel eindig? .

[Pooh]

Volgens mij is het allerbelangrijkste onderdeel van OO inheritance, maar misschien is dat de verderfelijke erfenis van mijn studie...

Overigens is OO een programmeer-concept, geen taal-eigenschap. Er valt prima OO te programmeren in C, maar makkelijk is 't niet. C++ biedt vrijwel alle OO-mogelijkeheden native aan, dat scheelt een hoop werk. (Of 't in VB mogelijk is weet ik niet, ik heb 't nooit geprobeerd)

[whoami]

Laat ons zeggen dat C++ de belangrijkste 'bouwstenen', 'basisconcepten' van OO bevat. VB bevat die niet.

[Verwijderd]

Op zondag 23 juni 2002 17:19 schreef pkouwer het volgende:
Ik hoorde laatst collega's roepen dat VB geen echte O-taal is en bv C++ wel. Nu weet ik er zelf te weinig vanaf om daarover te oordelen, maar op welke basis is een taal wel of geen OO-taal. Deze vraag is puur interesse: wil het gewoon weten )

Het heeft geen inheritence en geen polymorphism.

C++ is volgens de puristen overigens ook geen OO taal, je kunt in C++ namelijk een programma maken dat geen classes gebruikt of wat voor OO specifieke aspecten dan ook.

Ik vind het allemaal wat geneuzel. Object oriented bezig zijn is IMHO bezig zijn met objecten. Of je dan praat over COM objects of over objects gecreeerd uit classes, het zal.

[Verwijderd]

Op zondag 23 juni 2002 22:37 schreef whoami het volgende:
friend functies vind ik inderdaad geen kenmerk van een OO - taal...

De meeste mensen zijn er het toch wel over eens, dat de kenmerken van een OO taal:
- data encapsulation / data hiding
- data abstraction
[...]
zijn.

Juist deze dingen heeft VB wel

[whoami]

Op maandag 24 juni 2002 09:51 schreef Otis het volgende:

[..]

Juist deze dingen heeft VB wel

Deze 2 wel, maar die andere 2 niet...

[Verwijderd]

Op maandag 24 juni 2002 08:23 schreef Poohbear het volgende:
Overigens is OO een programmeer-concept, geen taal-eigenschap. Er valt prima OO te programmeren in C, maar makkelijk is 't niet. C++ biedt vrijwel alle OO-mogelijkeheden native aan, dat scheelt een hoop werk. (Of 't in VB mogelijk is weet ik niet, ik heb 't nooit geprobeerd)

Jij snapt het.

In VB is het bouwen van inheritence erg lastig. Er zijn wel mensen die het hebben geprobeerd en beweren dat wat zij hebben gemaakt ook werkt, maar feitelijk is dat meer aggregation dan echte inheritence. In VB kun je wel met COM objects in de weer, wat in feite ook is wat je wilt: je creeert instances van objects, die geef je een opdracht en die zoekt het verder dan ook maar uit. Object klaar? object destroyen. Dat is het voordeel van OO: data-oriented denken, dus een stukje data met de bijbehorende methods.

Dat je inheritence kunt gebruiken voor het omzeilen van veel typewerk is leuk, maar het is niet de enige manier. In C geschreven COM objects doen in VB hetzelfde.

Het nadeel van een pure OO taal is dat je ook altijd OO bezig moet zijn, dus data-oriented: alles zit altijd in een class en je moet altijd met objects werken. Maar een functielibrary laat zich semantisch maar erg slecht in een data-oriented jasje proppen. C++ is IMHO in dat opzicht beter: procedure-oriented waar nodig en data-oriented ook waar nodig. Alleen die syntax he...

[Verwijderd]

De meeste mensen zijn er het toch wel over eens, dat de kenmerken van een OO taal:
- data encapsulation / data hiding
- data abstraction
- inheritance
- polymorphisme

De taal Haskell voldoet aan deze eigenschappen. Noem je dat een OO-taal? (functionele talen vallen schematisch in een ander paradigma).

OO als programmeerconcept kan je wel toepassen in Haskell, maar het ziet er dan wel anders uit dan in talen als java of c++.

[Soultaker]

Op maandag 24 juni 2002 10:49 schreef lnfinitive het volgende:
De taal Haskell voldoet aan deze eigenschappen. Noem je dat een OO-taal? (functionele talen vallen schematisch in een ander paradigma).

Ik moet bekennen dat ik nooit met Haskell gewerkt heb (al ben ik wel bekend met functioneel programmeren), dus eventuele stomme opmerkingen mogen gecorrigeerd worden.

Ik denk echter dat een fundamenteel onderdeel van OO programmeren het representeren van staat in objecten is (objecten zijn, zoals al is gezegd, stukken data met het bijbehorende gedrag). Er bestaan wel objecten zonder staat (toolkits e.d.) maar die zijn vanuit OO oogpunt nauwelijks interessant.

Een functionele programmeertaal bevat doorgeens geen concept van staat (van de wereld of van een object) daardoor/doordat er niet zoiets is als een variabele.

Ik weet niet precies hoe het OO-deel van Haskell werkt, maar het lijkt me sterk dat er staat (member variables, attributes, of hoe je het ook noemt) aan objecten toegevoegd kan worden. Het grote voordeel van een functionele taal, het ontbreken van side-effects, is daarmee namelijk om zeep geholpen.

Een mogelijke wijze om toch OO te werken in een functionele taal is natuurlijk een nieuw object te retourneren als resultaat van een operatie op een andere object, maar dit is conceptueel toch iets heel anders dan het aanroepen van een methode van een object in een OO taal.

Zoals al eerder gezegd kun je in de meeste talen wel OO te werk gaan, maar een OO taal biedt alle relevante faciliteiten al uit zichzelf.

[.oisyn]

Op maandag 24 juni 2002 03:04 schreef mbravenboer het volgende:

[..]

Das een gevaarlijke uitspraak . Wat zijn OO mogelijkheden? Support C++ bijvoorbeeld double-dispatch/multi-methods? (das een retorische vraag ).

Is het domein van OO mogelijkheden uberhaupt wel eindig? .

idd, ik had erachter moeten zetten: "die hier vermeld zijn"

[Verwijderd]

VB is geen OO taal, VB.NET is dat wel.
Waarom is VB geen OO - taal?

Om object oriënted te zijn, moet een taal aan een aantal eigenschappen voldoen:

- abstraction
- data hiding, data encapsulation
- inheritance
- polymorphisme

Aangezien inheritance en polymorphisme niet mogelijk zijn in VB, is VB geen OO-taal.

Ik sluit me hier geheel bij aan.

Ik programmeer overigens zelf in C++ en Delphi. Delphi ondersteunt ook wel klassen net als VB maar is ook beperkt in de bovenstaande eigenschappen en om die reden ook geen OO taal.

[whoami]

Op maandag 24 juni 2002 16:59 schreef X-Fire het volgende:


Ik programmeer overigens zelf in C++ en Delphi. Delphi ondersteunt ook wel klassen net als VB maar is ook beperkt in de bovenstaande eigenschappen en om die reden ook geen OO taal.

Excuse me? Delphi is net wel OO (net als C++ hybride wel te verstaan). In Delphi heb je wel inheritance en heb je ook polymorphisme.

[Infinitive]

Een functionele programmeertaal bevat doorgeens geen concept van staat (van de wereld of van een object) daardoor/doordat er niet zoiets is als een variabele.

Per definitie heeft een functionele programmeertaal misschien geen state, maar aangezien je computer niet voorniets compute_r heet, moet het toch zoiets hebben. Conceptueel zou je de state van een functionele programmeertaal de stack kunnen noemen.

Tenzij ik het mis heb, is volgens mij dit ook de reden waarom Monads in Haskell kunnen werken (pak een object, doe er wat operaties op wat een "nieuw" object tot gevolg heeft waar verder mee gewerkt wordt).

Misschien dat je zou kunnen zeggen dat een functioneel programma geen state heeft, maar dat op functieniveau wel een soort van state bestaat, zoals gedefinieerd door je parameters en je return value.

doordat er niet zoiets is als een variabele.

Dat hangt af van je definitie van variable. Aangezien in een functionele taal alleen waarden een naam hebben en geen stukken geheugenruimte (hoewel je daar wel een relatie tussen kan bedenken) bestaan er geen variablen. Maar als je een variable de naam van een (deel van de) state noemt, dan zouden parameters als variablen gezien kunnen worden (die echter van buiten de functie "wijzigbaar" zijn, maar van binnen constant).

Een mogelijke wijze om toch OO te werken in een functionele taal is natuurlijk een nieuw object te retourneren als resultaat van een operatie op een andere object, maar dit is conceptueel toch iets heel anders dan het aanroepen van een methode van een object in een OO taal.

Ow, dat schreef ik dus net
Nu schreef ik in mijn originele post al dat OO als programmeerconcept in een functionele taal er anders uitziet, maar waar vind je het eigenlijk in verschillen? Omdat je oorspronkelijke object niet gewijzigd is? Maar bestaat een object eigenlijk wel in een functionele taal?

Ik weet niet precies hoe het OO-deel van Haskell werkt, maar het lijkt me sterk dat er staat (member variables, attributes, of hoe je het ook noemt) aan objecten toegevoegd kan worden.

Wat dat laatste betreft: zie tekst hierboven. Wat het eerste betreft: ik heb zelf alleen gewerkt met datastructuren waar ik de waarden via pattern mathing uithaal, echt gewerkt met concreet gewerkt met objecten met attributen heb ik niet ( ). Maar deze zijn er wel, en als voorbeeld kan ik zo ongeveer alle structures van de WIN32 API aanvoeren... bovendien zeggen whoami's vier punten niet echt iets over attributen of membervariablen.

Zoals al eerder gezegd kun je in de meeste talen wel OO te werk gaan, maar een OO taal biedt alle relevante faciliteiten al uit zichzelf.

En daar wordt het wat moeilijk, want welke relevante faciliteiten zijn er, zoals al eerder in dit topic opgemerkt is.
Nu begon ik mij post ook met het stellen of haskell een OO taal is, in vraagvorm, meer om aan te geven of de gegeven definitie van OO wel volledig is. Alleen met het maken van de vergelijking van een functionele taal met OO heb ik waarschijnlijk de woede van de hele funtionele wereld over me heen gehaald

_{Maar nu moet ik weer snel verder met een practicum opdracht in java, want de deadline is tot m'n schrik een week eerder dan ik dacht...}

[Soultaker]

Op maandag 24 juni 2002 21:34 schreef Infinitive het volgende:
Per definitie heeft een functionele programmeertaal misschien geen state, maar aangezien je computer niet voorniets compute_r heet, moet het toch zoiets hebben. Conceptueel zou je de state van een functionele programmeertaal de stack kunnen noemen.

Accoord, maar zoals al gezegd is, is het feit dat op een OO wijze te prorgammeren is geen voldoende argument om een programmeertaal een OO taal te noemen. In C kan ook prima OO geprogrammeerd worden (de eerste parameter van elke 'methode' noem je de 'this' pointer en new en delete wrap ik naar malloc en free; klaar).

_{Daarbij werkt een functionele programmeertaal natuurlijk niet altijd met een stack. Clean werkt bijvoorbeeld met graaf reductie en gaat dus niet zonder meer uit van een (lineaire) stack.}

Inderdaad wordt monad passing veel gebruikt om in functionele programmeertalen toch staat te kunnen modelleren (waar uiteindelijk niet aan te ontkomen valt, aangezien niet alle toepassingen parallel te modelleren zijn).

Tenzij ik het mis heb, is volgens mij dit ook de reden waarom Monads in Haskell kunnen werken (pak een object, doe er wat operaties op wat een "nieuw" object tot gevolg heeft waar verder mee gewerkt wordt).

Kunnen werken? Hoe bedoel je dat? Het lijkt me dat monad passing een manier is om OO gedrag te simuleren en niet andersom.

En daar wordt het wat moeilijk, want welke relevante faciliteiten zijn er, zoals al eerder in dit topic opgemerkt is.

Inderdaad. De functionele programmertalen die ik ken (eigenlijk alleen Clean en Miranda) voldoen daar niet uit zichzelf aan. Je hebt geen ongelijk, wanneer je de mogelijkheden van functionele programmeertalen beschrijft, maar onze definitie van OO functionaliteit verschilt.

_{Maar nu moet ik weer snel verder met een practicum opdracht in java, want de deadline is tot m'n schrik een week eerder dan ik dacht...}

Succes.

[Creepy]

Op maandag 24 juni 2002 17:02 schreef whoami het volgende:

[..]

Excuse me? Delphi is net wel OO (net als C++ hybride wel te verstaan). In Delphi heb je wel inheritance en heb je ook polymorphisme.

En ook abstractie en data hiding dus...

Dus als X-Fire ff wil toelichten waarom hij denkt dat Delphi er minder in is..

Trouwens toch wel grappig.. ik had lang niet verwacht dat dit topic op zo'n discussie zou uitlopen over wat wel en wat niet OO is.

Ik heb zelfs een keer met iemand gesproken die er heilig van overtuigd was dat Authorware (kent iemand dat hier? ) OO was. Ach ja... dezelfde persoon zou mij wel ff vertellen dat niet OO programeren uit de boze was, hij kon alleen niet onderbouwen waarom hij dat dacht. De opmerking "ja maar OO werkt zo mooi, alle objecten doen alles voor zichzelf" noem ik geen onderbouwing

[mbravenboer]

Infintive schreef een mooi verhaal over Haskell

Volgens mij heb jij een goedaardig virus opgelopen .

Creepy: dezelfde persoon zou mij wel ff vertellen dat niet OO programeren uit de boze was

Helaas is het vaak zo dat adviezen te vaak gebaseerd op een gebrek aan kennis van de adiesgever: kies OO, kies Java, kies PHP, kies MySQL: dit is de absolute oplossing! Dit betekent te vaak dat de adviesgever erg ervaren is in PHP, MySQL of OO en dus kan bedenken hoe je een bepaald probleem mooi kan oplossen in PHP, MySQL of OO.

Dat is op zich prima: mogelijkheden aangeven is nuttig. Het wordt gevaarlijk zodra je echter ook andere technieken gaat afraden of jouw techniek als 'de' techniek gaat presenteren. Je moet je dan als 'advies ontvanger' altijd goed afvragen waarop de adviesgever dit advies baseert. Kent hij beide omgevingen eigenlijk wel? Baseert hij zijn advies misschien op zijn minimale kennis van de afgraden techniek?

De opmerking "ja maar OO werkt zo mooi, alle objecten doen alles voor zichzelf" noem ik geen onderbouwing

Niet Nou, ik zou het zelf gezegd kunnen hebben .

[Creepy]

Ach.. die persoon had welgeteld een half jaar ervaring in de informatica wereld.. had een paar maanden ASP scripts geprogrammeerd, en 1 hele maand Authorware, en een klein beetje Delphi..

Ik neem niet zomaar iets aan.. ik moet overtuigd worden

Maar helaas gebeurt het vaak dat iemand iets zegt van "dit en dit is DE oplossing bla bla bla", daarvan heb ik er nog maar weinig gezien die me ook daadwerkelijk daarvan kunnen overtuigen (ik = stront eigenwijs ja hehe).

Ook een leuke van bepaalde mensen die er van overtuigd zijn dat OO altijd "THE way to go" is, is dat ze wel OO kunnen denken, maar zich weinig raad weten met de implementatie. Heb een paar maanden een collega gehad die dus objecten ging maken die al bestonden. Wat is nou (IMHO) 1 van de voordelen van OO: hergebruik! Maar nee hoor.... ook nadat ik hem gezegd had dat hij eens een paar andere objecten moest gaan bekijken, omdat die wel eens zouden kunnen wat hij "opnieuw" aan het maken was, ging hij dus stug door...

[.oisyn]

Op maandag 24 juni 2002 23:08 schreef Creepy het volgende:
Heb een paar maanden een collega gehad die dus objecten ging maken die al bestonden. Wat is nou (IMHO) 1 van de voordelen van OO: hergebruik! Maar nee hoor.... ook nadat ik hem gezegd had dat hij eens een paar andere objecten moest gaan bekijken, omdat die wel eens zouden kunnen wat hij "opnieuw" aan het maken was, ging hij dus stug door...

ligt er natuurlijk aan waarvoor je het maakt. Ikzelf heb ook overal implementaties van gemaakt die je eigenlijk gewoon overal en nergens vandaan kunt plukken. Dat maakt het er niet minder leuk er leerzaam door, aangezien je gewoon ervaring kweekt. In een productieve omgeving zoals op je werk is het natuurlijk een ander verhaal, want dan kost tijd geld, en is het dus ook beter als je het eerder af hebt.

(je hebt het over 'een collega', dus dat laatste zal het wel zijn )

Maar wat ik wil aangeven is dat het wiel opnieuw uitvinden totaal niet slecht is; je leert namelijk waarom bepaalde dingen geimplementeerd zijn zoals ze geimplementeerd zijn, en die kennis kun je ook weer gebruiken voor andere problemen die misschien later optreden.

[Infinitive]

Daarbij werkt een functionele programmeertaal natuurlijk niet altijd met een stack. Clean werkt bijvoorbeeld met graaf reductie en gaat dus niet zonder meer uit van een (lineaire) stack.

Dat maakt in principe natuurlijk niets uit: conceptueel wordt er data opgeslagen dat je kan beinvloeden, dus je state zul je hebben.
In werkelijkheid hoeft dat natuurlijk niet te zijn. Maak een slimme compiler die in de toekomst kan gluren (bij wijze van spreke natuurlijk) en je gecompileerde programma bestaat alleen uit het antwoord. Dus omdat je programma alleen uit een waarde bestaat heeft het tussentijds geen state gehad (je code is niet eens "uitgevoerd").
Maar bij dit soort eigenschapen kijk je niet naar de output van compiler/executie van je programma, maar juist naar de taal zelf. Dus als je zegt dat een taal die aan OO voldoet een staat moet hebben, wel, bij een functionele taal kan ik best wel een state aangeven ook al is deze er in werkelijkheid misschien niet.


_{Hoe Haskell precies de code uitvoert weet ik eigenlijk niet. Ik maakte per ongeluk wel een keer een klein foutje en kreeg een stack-trace van meer dan 20 pagina's... oeps}

Kunnen werken? Hoe bedoel je dat? Het lijkt me dat monad passing een manier is om OO gedrag te simuleren en niet andersom.

Ik bedoelde meer zoiets van dat je toch iets van een state moet hebben als Monads bestaan.

[qoute]
maar onze definitie van OO functionaliteit verschilt.
[/quote]
Daar was mijn vergelijking met Haskell nu juist voor bedoeld
quote van mezelf: "De taal Haskell voldoet aan deze eigenschappen. Noem je dat een OO-taal?"

Als bovendien we het al oneens zijn over deze paar eigenschappen, hoe krijg je dan overeenstemming over het geheel

Misschien kan je bij OO beter denken aan een verzameling taal/programmeer aspecten waarvan een OO taal een deelverzameling heeft. Deze deelverzameling kan je gebruiken om te beoordelen of die taal een handige keuze voor een bepaald probleem is.

[mOrPhie]

Op maandag 24 juni 2002 17:02 schreef whoami het volgende:

[..]

Excuse me? Delphi is net wel OO (net als C++ hybride wel te verstaan). In Delphi heb je wel inheritance en heb je ook polymorphisme.

Nu heb ik weinig ervaring met delphi, maar zover ik weet is de productmanager van delphi toen naar MS gegaan om daar een stukje VB.net/C# productmanagement te ondersteunen. De reden dat hij dat heeft gedaan is omdat hij de rest van de delphi-medewerkers niet kon overtuigen compleet OO te gaan ondersteunen in delphi. Er waren daar wat meningsverschillen over ontstaan.

Echter wil ik best geloven dat het minimaal een hybride-OO taal is. Naar wat ik heb gezien zag het er volwassen uit.

[whoami]

Op dinsdag 25 juni 2002 10:57 schreef mOrPhie het volgende:

Nu heb ik weinig ervaring met delphi, maar zover ik weet is de productmanager van delphi toen naar MS gegaan om daar een stukje VB.net/C# productmanagement te ondersteunen. De reden dat hij dat heeft gedaan is omdat hij de rest van de delphi-medewerkers niet kon overtuigen compleet OO te gaan ondersteunen in delphi. Er waren daar wat meningsverschillen over ontstaan.

De geestelijke vader van Delphi, Anders Hjelsberg is idd bij Borland weggegaan (reden weet ik niet) en hij heeft bij Microsoft onderdak gevonden. Bij Microsoft was hij verantwoordelijk voor het ontwerp van C#. (Ietsje meer dus dan enkel wat ondersteuning bieden, hij is daar product manager/chief designer van). Voor zijn 'achievements' heeft hij bij Microsoft de titel 'Microsoft Distinguished Engineer' voor gekregen.

Echter wil ik best geloven dat het minimaal een hybride-OO taal is. Naar wat ik heb gezien zag het er volwassen uit.

Delphi is zeer volwassen en totaal niet te vergelijken met VB imho.

[Creepy]

Op dinsdag 25 juni 2002 02:34 schreef .oisyn het volgende:

[..]

ligt er natuurlijk aan waarvoor je het maakt. Ikzelf heb ook overal implementaties van gemaakt die je eigenlijk gewoon overal en nergens vandaan kunt plukken. Dat maakt het er niet minder leuk er leerzaam door, aangezien je gewoon ervaring kweekt. In een productieve omgeving zoals op je werk is het natuurlijk een ander verhaal, want dan kost tijd geld, en is het dus ook beter als je het eerder af hebt.

(je hebt het over 'een collega', dus dat laatste zal het wel zijn )

Maar wat ik wil aangeven is dat het wiel opnieuw uitvinden totaal niet slecht is; je leert namelijk waarom bepaalde dingen geimplementeerd zijn zoals ze geimplementeerd zijn, en die kennis kun je ook weer gebruiken voor andere problemen die misschien later optreden.

Het wiel opnieuw uitvinden kan best leerzaam zijn ja

Maar is zeker niet handig als er een erg strakke deadline staat! Die collega was vlak daarna ook verdwenen, en kon ik dus zijn werk afmaken (wat al af had moeten zijn, en volgens hem ook al af was!)
(brr.. zo.. ook weer van die frustratie af )

[-DarkShadow-]

In Visual Basic 6 en lager loop je wel eens tegen de beperkingen van het OOP, maar in .NET is dat allemaal opgelos, wat er allemaal in VC++ zit, zit nu ook in VB.NET. Maar met een beetje creatieviteit lukt het ook wel in VB6 . Ik was met een structuur bezig voor een game engine op papier. Ik dacht dat wel ff uit te werken in VB6, nee ik was er 2 weken mee bezig. Dat kwam dus omdat ik bepaalde dingen uit de OOP miste, maar dat had ik met een omweg die niet veel langzamer is opgelost. Verder zweer ik bij VB6.

[.oisyn]

Op dinsdag 25 juni 2002 18:36 schreef -DarkShadow- het volgende:
wat er allemaal in VC++ zit, zit nu ook in VB.NET.

zoals bijvoorbeeld multiple inheritance?
.NET ondersteund dat niet als ik me niet vergis

[Verwijderd]

De originele vraagstelling:

Op zondag 23 juni 2002 17:19 schreef pkouwer het volgende:
Ik hoorde laatst collega's roepen dat VB geen echte O-taal is en bv C++ wel. ...

Een andere reden dat mensen dit zeggen is, dat het bij VB er vaak op neerkomt dat functies en sub's uit een module (bas) in een class (cls) gestopt zijn, en de auteurs vinden dat ze aan OO doen.

Maw: dat je een class-file hebt betekent niet dat je aan OO doet. (een ander voorbeeld, ik kwam laatst een requirments document tegen waar Functioneel Ontwerp op stond. Tja, zo gemakkelijk is het niet).

Ik denk dat je in VB best OO kan doen, maar als je COM objecten maakt voor server-gebruik, wil je dit niet. Dat ligt natuurlijk voor een groot deel aan COM

Gelukkig is C# bedacht

[whoami]

Op dinsdag 25 juni 2002 20:46 schreef .oisyn het volgende:

Zoals bijvoorbeeld multiple inheritance?
.NET ondersteund dat niet als ik me niet vergis

Inderdaad... Maar dat is ook niet nodig.

Templates zitten er ook niet in... (Maar is dat één van de vereisten om een taal OO te maken?).

Aan wat moet een taal minimum voldoen om OO te zijn?
- mogelijkheid tot code-hergebruik
- data-abstractie.

[-DarkShadow-]

Op dinsdag 25 juni 2002 20:46 schreef .oisyn het volgende:

[..]

zoals bijvoorbeeld multiple inheritance?
.NET ondersteund dat niet als ik me niet vergis

ké, niet alles, maar wel veel essentiele dingen die eerst ontbraken. Ik bedoel dus dat het er qwa OOP op vooruit is gegaan.

[Verwijderd]

Op zondag 23 juni 2002 17:42 schreef whoami het volgende:
VB is geen OO taal, VB.NET is dat wel.

Waarom is VB geen OO - taal?

Om object oriënted te zijn, moet een taal aan een aantal eigenschappen voldoen:

- abstraction
- data hiding, data encapsulation
- inheritance
- polymorphisme

Aangezien inheritance en polymorphisme niet mogelijk zijn in VB, is VB geen OO-taal.

Even nuance. VB kan geen implementation-inheritance. Interface-inheritance doet VB best wel goed. Dat is ook de reden waarom polymorphisme heel goed mogelijk is in VB.

Implementation-inheritance is volgens mij ook zwaar overgewaardeerd.

Als je implementation-inheritance gaat doen, moet je werken met protected members. Hiermee creeer je een extra afhankelijkheid tussen super- en sub-class. En dat is wat je altijd probeert te minimaliseren: afhankelijkheid: zodat je objecten zich kunnen evolueren, zonder in een te strak keurslijf te moeten lopen.

OK, implementation-inheritance kan best handig zijn, maar dan moet je heel goed weten waar je mee bezig bent.

edit:
Code-reuse is overgewaardeerd. Vaak meer last dan lust.

[whoami]

Op dinsdag 25 juni 2002 21:16 schreef Doekman het volgende:

edit:
Code-reuse is overgewaardeerd. Vaak meer last dan lust.

Bwah, dat zeg jij.

Ik maak er handig gebruik van in m'n projecten. Ik maak enkele standaardschermen of classes met algemene functionaliteit. Daarvan inherit ik dan nieuwe schermen (of classes) die ik dan uitbreid met specifieke eigenschappen. Als ik iets wil veranderen in al m'n schermen, dan hoef ik het maar 1x te doen.

[Verwijderd]

Bwah, dat zeg jij.

Sterker nog, ik typte

Ik dikte het alleen even aan, omdat veel mensen er lyrisch over zijn. Zoals jij je geval beschrijft lijkt het idd nuttig, no offence intended

Maar stel je je eens een imp-inheritance objectenboom voor van 100+ objecten, in een project binnen een bedrijf waar meerdere mensen mee bezig zijn, en dat al een paar jaar loopt. Dan kan je architectuur aardig vast lopen (en bedenk ook even dat er nog systemen draaien van 20 jaar oud. Software, ook al wordt het geschreven om een jaartje te gebruiken, leeft vaak langer!)

[mbravenboer]

Doekman: Als je implementation-inheritance gaat doen, moet je werken met protected members. Hiermee creeer je een extra afhankelijkheid tussen super- en sub-class. En dat is wat je altijd probeert te minimaliseren: afhankelijkheid: zodat je objecten zich kunnen evolueren, zonder in een te strak keurslijf te moeten lopen.

Bij inheritance hoef je helemaal niet met protected members of wat dan ook te werken en ook is de superclass natuurlijk niet afhankelijk van de subclass. Dat de subclass afhankelijk is van de superclass is nogal logisch.

Inheritance is juist bedoeld voor het specialiseren en uitbreiden van functionaliteit. Je kunt met behulp van inheritance functionaliteit aan een basis-klasse toevoegen of functionaliteit specialiseren.

OK, implementation-inheritance kan best handig zijn, maar dan moet je heel goed weten waar je mee bezig bent.

Mwah, dat vind ik toch wel wat zwaar overtrokken hoor? Sinds wanneer is single-inheritance zo ontzettend ingewikkeld en tricky? Je moet het wel leren gebruiken, maar dat geldt voor alle taal features.

Code-reuse is overgewaardeerd. Vaak meer last dan lust.

Niet alle hergebruik van code is uiteraard gebaseerd op inheritance.

Verder is hergebruik slechts een gevolg van het toepassen van inheritance. Inheritance pas je toe als je bepaalde functionaliteit wilt specialiseren of als je in twee of meer takken van functionaliteit een logische gemeenschappelijk basis kunt ontdekken.

Het klinkt een beetje als 'mijn taal is kent feature A niet', oh maar dat geeft niet: feature A is ook best eng/lastig/onnodig . Het nut van inheritance van impelementatie betwijfelen is toch wel erg gedurft .

[mbravenboer]

Doekman: Maar stel je je eens een imp-inheritance objectenboom voor van 100+ objecten

Klassen .

Klasse structuren van 100 klassen of dieper komen zelden of nooit voor en inderdaad moet je je dan serieus afvragen of je goed bezig bent. Niet voor niets beschrijft Martin Fowler in zijn Refactoring boek ook een refactoring om inheritance om te zetten in delegatie (voor de gelukkige bezitter van dit meesterwerkje: blz 352 ). De kern van deze refactoring is dat je moet kijken welke rollen een klasse speelt. Als een kasse meerdere rollen speelt heb je namelijk een probleem als je deze rollen wilt gaan specialiseren: je kunt wel een subklasse maken die rol A specialiseert en een klasse die rol B specialeerst, maar moet je dan ook een klasse hebben die rol A en B specialiseert? Zolang je klasse maar 1 rol vervult is er niets aan de hand en kan je rustig deze rol specializeren.

Je zult vrijwel nooit hierarchien met een diepte groter dan 10 tot 15 tegenkomen: kijk maar eens op de poster van alle Java klassen: in GUI bibliotheken loopt de diepte misschien op tot 6 of 7, maar daar heb je het dan toch ook echt wel mee gehad. 100 is echter een krankzinnig getal .

[mbravenboer]

whoami: Templates zitten er ook niet in... (Maar is dat één van de vereisten om een taal OO te maken?).

Generics zijn in ieder geval wel een vereiste om het werken met een OO taal als Java of C# echt plezierig te maken .

[whoami]

Op dinsdag 25 juni 2002 23:22 schreef mbravenboer het volgende:
Je zult vrijwel nooit hierarchien met een diepte groter dan 10 tot 15 tegenkomen: kijk maar eens op de poster van alle Java klassen: in GUI bibliotheken loopt de diepte misschien op tot 6 of 7, maar daar heb je het dan toch ook echt wel mee gehad. 100 is echter een krankzinnig getal .

Inderdaad, als ik een class-hierarchy met een diepte van 15 of meer tegenkom, dan zou ik toch aan het ontwerp gaan twijfelen denk ik...

[Verwijderd]

Hmm. Ok, ik geef toe dat ik een beetje te veel Don Box heb nagepraat. Touche.

Verder moet je niet denken dat VB mijn taal is (ik ben er toe veroordeeld ), maar als iemand gaat zeggen dat VB geen inheritance of polymorphism ondersteund, moet er even ingegrepen worden

[mbravenboer]

Doekman: Don Box

Gevaarlijke man om na te praten . Straks ga je SOAP nog mooi en compact vinden .