SWC FlashDevelop + getDefinitionbyName

[flash_newbie]

Hi,
wollte das nur mal festhalten (auch für mich):

Wenn man FlashDevelop benutzt und aus einer .swc dynamisch Instanzen generieren will, muss beim Hinzufügen (in Flash Develop Rechtsklick auf swc -> Add To Library, danach nochmal Rechtsklick darauf und unter Options
"Included Library (include completly)" ausgewählt sein. Ansonsten gibts folgenden Fehler:
"[Fault] exception, information=ReferenceError: Error #1065: Variable XYZ is not defined."

Hintergrund: Standardmäßig wird nur das eingebunden, was auch wirklich referenziert wurde (Library (include referenced classes))


Also falls ihr sowas verwendet und mit FD arbeitet, sicherstellen, dass die komplette SWC importiert wurde.

PHP-Code:

            var letterRef:Class = getDefinitionByName( i + path ) as Class;
            var letterSprite:Sprite = new letterRef(); 


Inwieweit dieses dynamische Typisieren sich negativ auf die Performance auswirkt, werd ich dann noch merken (ios Projekt...)

[Omega Psi]

Wenn du einen Typ aus einer SWC referenzierst, musst du ihn auch in die SWF kompilieren. Für gewöhnlich geschieht das automatisch, da die import Direktive den Katalog von Klassen erzeugt, die in die SWF sollen. Da du über getDefinitionByName keine Klasse direkt verwendest, werden diese auch nicht gelinkt.

Über Compiler Argument kann man das aber steuern. Da musst du aber mal die Referenz konsultieren, das hab ich gerade nicht im Kopf.

[Martin Kraft]

Wieso verwendest Du nicht einfach sauber referenzierte Klassennamen?

Dynamische Konstruktionen wie getDefinitionByName sind doch nur potentielle FehlerQuellen?! Und da man die Klassennamen in der IDE eh alle händisch vergeben muss, sehe ich nicht wo da der Vorteil liegt?!

[flash_newbie]

@Martin
es handelt sich um ein Basisklasse mit Animationen die mit zusätzlichen Grafikattributen ausgestattet werden soll. Dies soll möglichst universell und dynamisch sein (es gibt ca. 40 Möglichkeiten, wie sie kombiniert wird).
Ich glaube, dass ich so mit der dyn. Typisierung das für mich am einfachsten lösen kann. Aber vielleicht ist das auch Unsinn.
Bin mal gespannt ob das so funtkionietrt wie ich es mir vorstell.

[Omega Psi]

Naja, die Fehler kann man ja schon arg einschränken und auch über Caching die Zugriffszeiten optimieren (ich hab da aber auch keine Benchmarks zu):

const _cache:Object = {};
function getNewInstanceFrom(qualifiedClassName:String):Object
{
  var ClassDef:Class
  if (_cache[qualifiedClassName])
  {
    ClassDef = _cache[qualifiedClassName] as Class
    return new ClassDef();
  }

  ClassDef = getDefinitionByName(qualifiedClassName) as Class;
  if (!ClassDef)
  {
    throw new ArgumentError('Could not find Class for name '+ qualifiedClassName);
  }

  return new (_cache[qualifiedClassName] = ClassDef)();
}

[Martin Kraft]

@Omega Psi:
Was einen aber immer noch nicht des Problems entledigt, die so generierten Instanzen dann auf irgendwas casten zu müssen um damit arbeiten zu können. Auf Object oder * zu typisieren ist mir persönlich ein Graus und zudem ein Einfallstor für Laufzeitfehler

Ich bleibe daher dabei: Man sollte, wo immer möglich, auf solche dynamischen Konstruktionen verzichten und stattdessen die Klassen sauber statisch referenzieren.


@flash_newbie:

Zitat von flash_newbie

@Martin
es handelt sich um ein Basisklasse mit Animationen die mit zusätzlichen Grafikattributen ausgestattet werden soll. Dies soll möglichst universell und dynamisch sein (es gibt ca. 40 Möglichkeiten, wie sie kombiniert wird).

Beschreib mal genauer, was Du damit meinst! Da gibt es bestimmt eine besere Lösung

[Omega Psi]

Es geht doch nur um die Generierung von Instanzen. Und das "fehlerfreies" Laufzeitverhalten wird ja nicht durch Compile-Sicherheit gewährleistet, sondern durch Tests und Restriktion der Ein- und Ausgabeparameter für Methoden.

function getNewSpriteFrom(qualifiedClassName:String):Sprite
{
  const object:Object = getNewInstanceFrom(qualifiedClassName),
        sprite:Sprite = object as Sprite;

  if (!sprite)
  {
    throw new ArgumentError('Instance created from ' + qualifiedClassName + ' is no covariant instance of Sprite');
  }

  return sprite;
}

Also, wenn man solche Mechanismen isoliert, beispielsweise durch eine Factory, implementiert ist das nicht unvernünftig.

[thomas_E]

es handelt sich um ein Basisklasse mit Animationen die mit zusätzlichen Grafikattributen ausgestattet werden soll.

Das Klingt für mich aber eher nach einen Fall für eine vernünftige Komposition, nicht Vererbung+redundantem Code.
(~40 Klassen, die von 1. Basisklasse erben, und nur unterschiedliche Variationen derselben paar Ergänzungen darstellen)

Daher plädiere ich auch für mehr Infos bezüglich der konkreten Anforderung/Implementierung.

Zitat von Omega Psi

Also, wenn man solche Mechanismen isoliert, beispielsweise durch eine Factory, implementiert ist das nicht unvernünftig.

Einverstanden; dem kann ich so zustimmen.
Dennoch tendier ich auch eher dazu solche dynamischen Konstrukte zu vermeiden.
Ich schreib lieber ein statisches Array (eine Whitelist), mit den Klassen die verwendet werden können, als die Klassennamen zusammenzubauen.
Auf diese Weise kann es einfach nicht vorkommen, dass ein Klassenname falsch ist/die dazugehörige Klasse nicht existiert.

Ich bin mir sicher, dass auch dass irgendwo an seine Grenzen stoßen wird, aber da war ich bisher nicht. Und wenn ich mal da lande, weiss ich ja, wo ich nachlesen kann

[Omega Psi]

Aber das ist das gleiche in rot. Ob man nun eine Whitelist verwendet oder sich die Klassennamen an anderer Stelle zusammenbaut. Die Fehlerquellen sind die gleichen und kann man einfach über Unittests abfangen.

[Omega Psi]

Oder nicht?

[thomas_E]

Die Fehlerquellen kann ich grad nicht abschätzen, die Fehler an sich sind ähnlich. In jedem Fall sind es Laufzeitfehler, die wir beide hier abfangen müssen.

Aber das gleitet in eine Diskussion über persönliche Präferenzen und Programmierstil ab.
Ich wollt nur meinen Senf dazu geben, wie ich an die Sache rangehen würde.

Ob nun das eine, oder das andere. Ich finde hier beides fehl am platz, und wie oben schon geschrieben, hört es sich für mich so an, dass man hier besser das Objekt anhand der Anforderungen zusammenbaut, als dass man hier eine von x "gleichen" Klassennamen zusammenbaut, Klasse raussucht und instanziert.

Gut soweit?

ich finde jetzt ist wieder flash_newbie gefragt; uns noch paar Infos zu dem Konstrukt zu geben, dass er da baut/bauen will. Dafür revanchieren wir und mit Lösungsvorschlägen

[Oxigan]

Zitat von Martin Kraft

Wieso verwendest Du nicht einfach sauber referenzierte Klassennamen?

Dynamische Konstruktionen wie getDefinitionByName sind doch nur potentielle FehlerQuellen?! Und da man die Klassennamen in der IDE eh alle händisch vergeben muss, sehe ich nicht wo da der Vorteil liegt?!

Sehe ich nicht so. Das ist ziemlich essentiell z.B. für den Factory-Pattern. Ich benutze das "relativ" oft. Weil es - sinnvoll eingesetzt - sehr sehr nützlich ist.

LG

[Omega Psi]

Zitat von thomas_E

Gut soweit?

Yes

[Martin Kraft]

Zitat von Oxigan

Sehe ich nicht so. Das ist ziemlich essentiell z.B. für den Factory-Pattern. Ich benutze das "relativ" oft. Weil es - sinnvoll eingesetzt - sehr sehr nützlich ist.

Nur sollte diese Factory IMHO eben sauber typisierte Instanzen (z.B. Sprites) zurückliefern und keine Klassen von denen keiner weiß, was drinsteckt...


Aber, wie Thomas schon sagte: Es ist jetzt an flash_newbie uns einen tieferen Einblick in das Vorhaben zu gewähren, bei dem wir ihm helfen sollen.

[Omega Psi]

Man kann die Factory doch entsprechend implementieren.