* ) Core support of events, based like mocks.
interface MyListener {
onMyEvent (content:String):String;
}
class MyController extends EventSupport implements EventSource sends MyListener {
// "sends" is only allowed if EventSource is implemented. EventSupport represents a out-of-the-box implementation
public myCode():List<String> {
result:List<String> = event MyListener.onMyEvent("hello"); // Strange possible syntax
return result; // returns the content of all events.
}
public myOtherCode() {
listeners:MyListener = getDistributor(MyListener); // conventional approach
listeners.onMyEvent("hello");
}
}
There should be a basic place of events to handle events:
package rfc.event {
class Event {
static native consume(); // consumes the execution of the current event.
static native getSource():EventSource; // information about the eventsender instance
}
}
* ) no "function" or "var" keyword. - They are simply not necessary.
* ) overloading ... i think we shouldn't have to discuss about that since there are interfaces and proper implementations of multiple interfaces need overloading. Else you will get problems - like in as2 with implementing multiple interfaces that define the same method with different parameters. You could possibly workaround it with accepting the i... notation for arguments for multiple inheritance. But therefore it would be great to implement overloading in programmstyle.
* ) Interfaces should contain a definition restriction for constructors:
interface MyInterface {
public MyInterface(a:String, b:String);
}
this would reduce the requirements of Factories with using
class MyClass {
public doSomthng(clazz:Class<MyInterface>) {
instance:MyInterface = new clazz("a", "b");
}
}
*.) Naming restriction of classes to 1.character uppercase and naming restriction to methods to 1.character lowercase. (to be discussable)
*) Proxies should work language based (else they can't be compile-time checked):
class MyProxy extends <T> { // extends <Type> automatically signs it as Proxy.
public handleCall(methodName:String, args:Array, argumentTypes:Array, returnType:Class) {
// handleCall with this parameters is required.
}
public anyMethod() {
// overwrites handleCall
}
}
class MyClass {
public doSmthng() {
instance:MyOtherClass = new MyProxy<MyOtherClass>();
}
}
Doing that with any different api than native is a.) complex and b.) taking you to much work to actually support something like this.
*) Would be nice to
*) Reflections would be nice - of course:
public rfc.core.Object {
public getType():Class;
}
public rfc.core.Class extends Type {
public getExtendedClass():Class;
public getImplementedInterfaces():List<Interface>
public getPublicMethods():Map<String, Method>;
public getPrivateMethods():Map<String, Method>;
public getProtectedMethods():Map<String, Method>;
public getPublicProperties():Map<String, Property>;
public getPrivateProperties():Map<String, Property>;
public getProtectedProperties():Map<String, Property>;
}
public rfc.core.Type {
public getName():String;
public getFullName():String;
public getParentPackage():Package;
public getEvents():List<Interface>;
public getMethods():Map<String, Method>;
public getProperties():Map<String, Property>;
}
public rfc.core.Interface extends Type{
public getExtendedInterfaces():List<Interface>;
}
*) I would not suggest to introduce a "Singleton" construct, therefore are better - configuration based - solutions available (no need for language support)
Just some thoughts.
2005/10/30, Ralf Bokelberg <[EMAIL PROTECTED]>:
Also what about something like adhoc interfaces?
// declare a interface, which contains the method m1
adhoc interface HasM1 {
public int m1 ( int p1, String p2);
}
// use the interface HasM1 as parameter type
class C {
public void test( HasM1 x){
int xResult = x.m1( 1, "hello");
}
}
// a class which "implements" the adhoc interface doesn't need to know
// about the interface, it only has to conform to it.
class A {
public int m1 ( int p1, String p2){
//...
}
}
// another class which "implements" the adhoc interface
class B {
public int m1 ( int p1, String p2){
//...
}
}
Instances of both of the classes A and B could be used as parameter to
C.test. I think, this could be useful if you have to work with third
party libraries. It helps to avoid a lot of adapter code.
Cheers,
Ralf.
Nicolas Cannasse wrote:
> Hi folks,
>
> The new still-unamed language specifications have been updated at
> http://ncannasse.free.fr/files/flexible.html . It now includes enumerators,
> Dynamic type parameters and a beginning of grammar rules.
>
> I would like to get comments about the design of the language : what are the
> features you've been dreaming about ? How should look for you the language
> you'll be happy to write in everyday at work ?
>
> It's an open discussion, so bring your ideas in . I have my own ones, but I
> think opening the design to everybody will result in a better result in the
> end.
>
> Have fun !
>
> Nicolas
>
>
> _______________________________________________
> osflash mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
