Schrift
[thread]11513[/thread]

Ein paar Programmiertricks (Seite 4)

Leser: 1


<< |< 1 2 3 4 >| >> 40 Einträge, 4 Seiten
Struppi
 2008-03-27 12:54
#107537 #107537
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
Jetzt sind wir soweit wie im selfhtml Thread. Diese Funktion entspricht der Funktion die Douglas Crockford hier beschreibt http://javascript.crockford.com/prototypal.html, nur daß er Object.prototype unberührt läßt, was auch ratsam ist, da du ansonsten Probleme bekommst, wenn du über for(x in y) auf die Eigenschaften von irgendwelchen Objekten zugreifen möchtest.
KurtZ
 2008-03-27 14:12
#107539 #107539
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
Struppi+2008-03-26 09:40:36--
KurtZ+2008-03-25 21:10:26--
ein Klassenobjekt wird als Funktion deklariert und kann höchstens erben:
Code: (dl )
  Klasse1.prototype= new Klasse0(); 


das folgende erzeugt aber ne Fehlermeldung
Code: (dl )
  Unterinstanz=new Instanz(); // Fehler: Instanz is not a constructor 


Deine erste Erläuterung verstehe ich nicht. Da es keine Klassen gibt, gibt es auch kein Klassenobjekt, jede Funktion ist erstmal per se ein Konstruktor ...


Jeder Konstruktor ist eine Funktion (und damit ein Objekt) mit einem Attribut "prototype"!
Also normale Funktionen "könnten" zu Konstruktoren werden, denn erst wenn man new auf sie anwendet, dann bekommen sie automatisch ein Unterobjekt prototype verpasst, sonst haben sie keins.

Man kann technisch also sehr gut unterscheiden zwischen Instanzobjekten und Konstruktorobjekten, letztere sollte man immer "Groß" schreiben und stehen technisch in Analogie zu Klassendefinitionen.

Bei diesem begetObject resp. clone Funktion werden im Grunde nur noch Konstruktorobjekte erzeugt und auf Instanzobjekte verzichtet.


Struppi+2008-03-26 09:40:36--
Im zweiten Fall könnte man sich noch behelfen in dem man schreibt:

Code: (dl )
  var Unterinstanz=new Instanz.constructor(); 


Wirklich? constructor liefert mir in meinen Tests das Ende der prototype-chain, also Urahn und nicht den Vater.


Struppi+2008-03-26 09:40:36--
Das sehe ich anders, Vererbung ist mit JS umständlich, einmal hast du keinen direkten Zugriff auf SUPER und zum zweiten wird durch new BasisKlasse() immer eine Instanz der Basis Klasse erzeugt, was zur Folge hat, das der Konstruktor aufgerufen wird und du dort aufpassen musst, wenn du eine für jede Instanz unterschiedliche Initialisierung machen willst, das geht in die Hose. Du musst entweder die Intialisierung in eine Funktion verlagern oder den Weg, den dir Don P im selfhtml Forum gezeigt hat wählen.


für constructor-chaining mit SUPER kannst du ja apply und call benutzen.
da der prototyp einer Klasse immer auch Instanz einer Superklasse ist muss man aufpassen, wie man Instanzen erzeugt, z.B. abhängig von den Parametern bei new.
TMTOWTDYOG (there's more than one way to dig your own grave)
KurtZ
 2008-03-27 14:12
#107540 #107540
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
Hi


Struppi+2008-03-27 11:54:16--
nur daß er Object.prototype unberührt läßt, was auch ratsam ist, da du ansonsten Probleme bekommst, wenn du über for(x in y) auf die Eigenschaften von irgendwelchen Objekten zugreifen möchtest.


nö!
Crockford macht genau den gleichen Fehler mit
Code: (dl )
1
2
3
4
5
Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();
};

siehe http://forum.de.selfhtml.org/?t=168754&m=1102196

Struppi+2008-03-27 11:54:16--
Jetzt sind wir soweit wie im selfhtml Thread. Diese Funktion entspricht der Funktion die Douglas Crockford hier beschreibt http://javascript.crockford.com/prototypal.html,


was haltet ihr beide davon dort weiterzudiskutieren, schließlich ist das hier ein Perlforum und wir sind mittlerweile voll auf JS. (Es sei denn wir nehmen uns die CPAN-Module zu prototypischen Vererbung vor :)
TMTOWTDYOG (there's more than one way to dig your own grave)
renee
 2008-03-27 14:30
#107543 #107543
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Ihr könnt das auch unter "Sonstige Beiträge" weiterdiskutieren...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
KurtZ
 2008-03-27 16:19
#107557 #107557
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
@Murphy:

Um unsere Meinen Standpunkt in unserer Diskussion auf auf den Punkt zu bringen, hier ein Vergleichsartikel bei Mozilla der darlegt wieso JS keine Klassen kenne:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages

Wenn man aber dieser Argumentation folgt, ist Perl auch nicht Klassenbasiert sondern sein Objektmodell emuliert nur Klassen!

Z.B. es gibt kein "class" Kommando, und die Klassen kann auch ich auch zur Laufzeit manipulieren. Private Methoden und Variablen muss ich ähnlich zu JS mit My und Closures simulieren.

Nimmt man also Java und C++ als Standard dann haben diese Sprachen also das normative Monopol auf den Begriff Klassen.

Perl ist also "package-basiert" und da ich irgendwo gelesen habe das Larry Wall sein Objektmodell bei Python abgeschaut hat, betrifft das auch andere Sprachen.
TMTOWTDYOG (there's more than one way to dig your own grave)
murphy
 2008-03-27 21:06
#107562 #107562
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
KurtZ+2008-03-27 15:19:24--
Z.B. es gibt kein "class" Kommando, und die Klassen kann auch ich auch zur Laufzeit manipulieren. Private Methoden und Variablen muss ich ähnlich zu JS mit My und Closures simulieren.
[...]


Ich finde das ist etwas weit her geholt. Bei Perl heißt das Statement eben nicht class sondern package :-)

Wenn man Deiner Argumentation folgen will, dann kann man auch behaupten, dass man in Java die Klassen zur Laufzeit verändern kann (man muss dazu lediglich einen neuen Classloader definieren und den Binärcode der Klassen beim Laden anpassen, wofür es einige gute Bibliotheken gibt) und private Variablen nicht mal durch Closures emuliert werden können, da man die Zugriffskontrollen mittels Reflection komplett umgehen kann.

Ach ja, und in C++ kann man natürlich sowieso den Kernel anweisen, die Speicherseiten mit dem Code der Klassen schreibbar zu mappen, so dass man auch hier den Code zur Laufzeit verändern kann und mit etwas Zeigerarithmetik kommt man um jegliche Zugriffsbeschränkung für Instanzfelder herum.

Ist damit nun etwa bewiesen, dass C++ und Java keine echte klassenbasierte Objektorientierung haben?

Ich kann auch in Assembler Code generieren, der voll dem prototypenbasierten Objektmodell entspricht. Das geht da sogar einfacher als in C++. Ist Assembler deswegen eine Programmiersprache mit prototypenbasierter Objektorientierung?

Aber wie auch immer, ich glaube, wir kommen mit der Diskussion nicht nur vom Thema ab, sondern begeben uns auch langsam in den Bereich der reinen Geschmacksfragen. Und das sollten wir besser bleiben lassen...
When C++ is your hammer, every problem looks like your thumb.
murphy
 2008-03-28 03:34
#107581 #107581
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
edit: Dieser Beitrag ist, wie ich später festgestellt habe, Quatsch. Wer weiter liest, ist selber schuld ;-)

Nachtrag zum Klonen von Objekten: Auch wenn der ECMA-262 Standard das nicht zwingend vorschreibt, habe ich festgestellt, dass sowohl SpiderMonkey (JavaScript-Engine von Firefox und Co) als auch JavaScriptCore (JavaScript-Engine von Konqueror, Safari und Co) das folgende Idiom zum Klonen eines Objektes unterstützen:
Code: (dl )
var clone = new Object(original);


Dieser Aufruf hat fast denselben Effekt wie die weiter oben vorgeschlagene clone-Methode. Der Unterschied ist, dass er für die statischen eingebauten Objekte (wie Object) keinen Klon anfertigt, sondern das Objekt selbst wieder zurückgibt und ferner dass er auch mit Eingabewerten klar kommt, die Arrays, Strings, Zahlen, null oder undef sind. Eigentlich ein sehr sinnvolles Verhalten :-)
When C++ is your hammer, every problem looks like your thumb.
KurtZ
 2008-03-28 13:07
#107593 #107593
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
Sehr interessant, habe das auch mal irgendwo gelesen, allerdings kann ich es nicht in der JS 1.5 Netscape Spezifikation finden. Hast du irgendwo ne Referenz???
TMTOWTDYOG (there's more than one way to dig your own grave)
Linuxer
 2008-03-28 13:31
#107596 #107596
User since
2006-01-27
3891 Artikel
HausmeisterIn

user image
Schön, dass ihr so angeregt über dieses Thema diskutieren könnt.
Aber könnt Ihr das nicht in einem anderen Subforum tun?

Eine ausschweifende Diskussion über JavaScript passt hier doch wirklich nicht mehr rein (weder in das Subforum noch in den Thread, der initial nach Tips für OO Perl fragte)...
meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
KurtZ
 2008-03-28 14:18
#107599 #107599
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
THREADDRIFT

@Murphy: Meine Antwort als SELFHTML-JS-POSTING

wie gesagt Selfhtml wär mir lieber! Dort ist JS Topic, und mehrere Leute interessieren sich dort auch für prototypische Vererbung.

Obwohl wir den Thread hier schon mehrmals begraben haben, gibts scheints immer wieder was. Das prototypische Vererbung Thema in Perl wird, ist auch nicht vermittelbar.
TMTOWTDYOG (there's more than one way to dig your own grave)
<< |< 1 2 3 4 >| >> 40 Einträge, 4 Seiten



View all threads created 2008-03-22 23:16.