On Tue, Dec 2, 2008 at 10:24 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
If you add (non-overriden) fields to a val, they'll always be invoked via
reflection, which takes a performance hit. Objects, on the other hand,
define their own class so reflection isn't necessary.
Can you give an
class Foo
// type is singleton type Bar.type
object Bar extends Foo {
def exc = (new Exception).printStackTrace
}
// type is structural type Foo{def exc: Unit}
val Baz = new Foo {
def exc = (new Exception).printStackTrace
}
// compare:
Bar.exc
Baz.exc
Singleton
I did some benchmarks. Accessing new methods is 50% slowere vs objects. On
the other hand, accessing existing methods is faster because acessing vals
is faster than accessing objects.
On Dec 2, 2008 10:24 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
If you add (non-overriden) fields to a val,
Quite right ... still I don't quite see why someone would use a Field
as structural type (.. or as anonymous instance) and define new -
overridden functions and invoke them later. Field should only override
functions to adapt the behavior for the needed situation.
Nevertheless it is a very good
So the short answer is, if you want to use Field as a structural type and
override functions on that type, you're better off defining a new Field
subtype or a trait with the appropriate behavior than doing it inline as an
anonymous class, if you want to avoid the performance hit.
I'm okay with
I agree. Fields should be perfectly functional by just overriding members.
But it should be mentioned in docs, etc as Lift best practices to not add
methods or fields inside of Fields.
--j
On Tue, Dec 2, 2008 at 1:01 PM, Marius [EMAIL PROTECTED] wrote:
Quite right ... still I don't quite see
Ok, I see now.
I don't think I've ever written something like that... I normally just
implement a trait in anonymous classes -- I don't usually extend it. It's
interesting to see that structural types leak so easily.
thanks!
alex
On Tue, Dec 2, 2008 at 10:51 AM, Jorge Ortiz [EMAIL PROTECTED]
I don't think it is a leak because in this case a structural type
has the same type with its parent, new entities (as Jorge explained)
are not visible from outside of that type boundaries and Scala
compiler still does a fair job to allow invocation of non-overridden
members.
For instance in Java
Yes, Scala is definitely smarter. I used the term leak loosely mostly
because I'm coming from the Java perspective and as you point out in Java
the method isn't accessible so there's no performance gotcha.
I'm happy Scala does what it does... and I'm glad Jorge pointed out this
little intricacy
On Tue, Dec 2, 2008 at 11:07 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
I agree. Fields should be perfectly functional by just overriding members.
But it should be mentioned in docs, etc as Lift best practices to not add
methods or fields inside of Fields.
I'm not sure I would call this a best
10 matches
Mail list logo
