Re: First Class Properties (Was: Partial Classes)
Daniel Dekany <ddekany <at> freemail.hu>
2007-07-02 12:17:52 GMT
Let me clarify a bit. What *I* tried to say -- which is maybe not what
Erik Engbrecht had in mind -- was about defining Bean properties in
Scala. The most important thing from my point of view was not
validation and whatever meta-info, but that Java stuff sees these
fictional Scala properties as Java Bean properties, rather than as
getter/setter methods with non-standard signatures or as fields.
The first question is if it would be a good idea to introduce a
special notation to define properties in classes. If it would be
useful enough. Like, in the simplest case:
class Foo {
prop foo = 0: Int
}
which in the case of the Java platform generates something like this
behind the scenes:
public class Foo {
private int prop$foo;
public int getFoo() {return prop$foo;}
public void setFoo(int v) {prop$foo = v;}
}
saving you from tedious work. (Why the Java language has still no such
feature? Now really, it's so silly.)
Also of course it would be possible to create more sophisticated
property definitions, like making a property read-only (like a val),
directly specifying the getter/setter functions and so on.
So, first it should be decided if such kind of feature is desirable. I
believe that at least if we think about Scala on Java platform, it
would be very useful. Then, if it is desirable and it was find out how
it should look, I think you will find that var/val members in classes
become a needless, because properties can do the the same and more.
That's why I brought up the idea that maybe var-s/val-s as class
members (i.e. I didn't mean inside methods/functions) should gone and
instead a class could only have properties as members (and methods,
types, etc of course).
But if this property feature becomes so heavyweight that using prop
instead of var/val means an overhead, that will prevent the removal of
var-s/val-s from classes, creating a much less clean situation. So
such overhead should be avoided in my approach to the topic.
--
Best regards,
Daniel Dekany
Monday, July 2, 2007, 12:53:05 PM, Viktor Klang wrote:
> Hello everybody,
>
> I've been lurking the mailinglist for about a week now and altough
> I have minimal experience using Scala I have 5+ years of Java-experience.
>
> Back on topic.
>
> I have some ideas concerning first class properties.
>
> What I'd like to be able to do for each property:
>
> declare a type
> declare a validator for that type
>
> I would also like to be able to get further information of the property:
>
> getType() //Returns the type of the property
> getEnclosingType() // returns type of enclosing object/class whatever
> getDeclaredName() //returns the name of the property in the enclosing type
> getValidator() //returns the validator specified when
> declaring/constructing the property
> set(ReferenceOfSameTypeAsEnclosingClass obj, TypeOfProperty value)
> //sets value of this property in obj
> get(ReferenceOfSameTypeAsEnclosingClass obj) //returns value of the porperty in obj
>
>
> conceptual idea: (written in semi-pseudo, semi-java, semi-scala)
>
> class Foo
> {
> property name: (String, RegexValidator("^blah~") )
> }
>
> def main(Array[Foo] foos, Array[Property[Foo]] fooProps)
> {
> for all foo in foos
> for all fooProp in fooProps
> print fooProp.get(foo)
> }
>
> Looks a bit sticky when I look on the code, and it could probably be cleaned up alot.
>
> Perhaps foo.fooProp would be the same as foo.name (if they are indeed the same property).
>
> foo.fooProp could be compiled to fooProp.get(foo) /
> fooProp.setFoo(foo,value) depending on usage.
>
>
> Also, validators and types are kinda redundant.
> The calidator itself must be aware of the type it validates, and
> so it would be unnessescary to declare the property with: "property
> name : (String,Regex...)" and perhaps "property name : Regex("^blah~")"
>
> where the type of Regex would be scala.String.
>
>
>
>
> Hmmm... do I make any sense?
>
>
> Best regards
> /Viktor Klang
>
>
> On 6/30/07, Daniel Dekany <ddekany <at> freemail.hu> wrote:
> Saturday, June 30, 2007, 3:26:27 PM, Erik Engbrecht wrote:
>
>> Bill,
>> Ok, since I introduced the term "first-class properties," I'll take
>> the first crack at providing a concise definition:
>>
>> 1. Properties are objects (OO sense, not necessarily Scala object
>> declaration sense) that govern access to a (possibly calculated)
>> field. This means properties can have other methods in addition to
>> get/set logic, such as registering event listeners.
>
> I'm newbie here at Scala, thus it can happen easily that I miss
> something obvious, but still... I wonder what's if instead of val-s
> and var-s and methods without argument list (for me that last feels
> like a dirty hack) we only had properties. Which then should be Java
> bean properties as well -- the Java world use this property concept a
> lot, so it would be nice. Wouldn't that be a cleaner concept? Even if
> in big part it is only the question of what name we give to things.
>
> BTW, I do realize that when I have var-s and val-s in a class that
> will generate setter/getter methods in the resulting Java class. I'm
> not sure how much is it just an implementation detail, but even if it
> is not just that, they are still not Java bean property
> setters/getters. They signatures are not like that.
>
>> and also the "def" syntax, which doesn't group everything into a single structural entity:
>> private var _name: String = "John Doe"
>> def name = _name
>> def name_=(v: String): Unit = _name = v
>
> (Is this something that should work with the current official release,
> 2.5.1? Not very elegant BTW...)
>
> --
> Best regards,
> Daniel Dekany
RSS Feed