Nice TWiki > Dev > FeatureProposals > DynamicMembers (r1.1) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }

Dynamic Members

This is the ability for a class to add members to their class at runtime. Actually, that's not what I'm proposing. I really want classes to be able to make it appear that they have other members at runtime. This could be implemented in (at least) two ways.

`.` Operator

One way would be to allow programmers to override the `.` operator. This would be very powerful, especially if the compiler would allow other things besides simple names after the dot, such as ints, floats, or booleans.

Examples

    Object `.`(row@Results, String column) {
        return rs.getObject(column);
    }
    Object `.`(row@Results, int column) {
        return rs.getObject(column);
    }

    Results row = connection.execSql("select fullName, address from Employees");
    String name = (String)row.1;
    String addr = (String)row.address;

If we had unknown implemented (see UnknownType) then this would be even cooler:

    unknown `.`(row@Results, String column) {
        return rs.getObject(column);
    }
    unknown `.`(row@Results, int column) {
        return rs.getObject(column);
    }

    Results row = connection.execSql("select fullName from Employees");
    String name = row.1;        // no type casting needed
    String addr = row.address;

Another advantage to overriding the `.` operator could be to implement dynamic method calls. I haven't explored this idea much, but it could be very powerful.

DynamicMember interface

If allowing an override of the `.` operator proved too difficult (darn), here's another possibility. We could have a special interface, maybe called DynamicMember, or just Dynamic. The compiler could assume that any class that implemented this interface would have a Object getMember(String name) method, or something similar. It would call this instead of it's normal field lookups.

Normal Members

The compiler needs to be intelligent enough, however, to do normal member lookups for the normal (public, protected, and private) members of the class. It would only do dynamic lookups when members are accessed which have not been declared. This means that dynamic members may not be found at runtime. Which necessitates a possibly new Exception class for this situation, which the programmer of the dynamic class would throw.

Reflection

It would be a really cool bonus, I think, if Nice could implement reflection on these dynamic members, so they would appear as if they were full-class citizens with the normal members of the class.

-- TroyHeninger - 25 Oct 2003

Topic DynamicMembers . { Edit | Attach | Ref-By | Printable | Diffs | r1.8 | > | r1.7 | > | r1.6 | More }
Revision r1.1 - 25 Oct 2003 - 04:44 GMT - TroyHeninger
Parents: WebHome > FeatureProposals
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.