Poll: virtual classes, good or bad?

It would be great if there was an explanation as to what virtual
classes are in the context of scala, perhaps an example or two. It
keeps getting mentioned as a 2.8.0 thing, although its never explained
further.

On 1/27/09, Sean McDirmid wrote:
>
>

I'm not sure if language support is so relevant. Basically, a virtual class is a nested class that you can override and refine when extending the parent class. You can already express them easily enough in Scala via a pattern, and someday we might get language support, but maybe not enough so the pattern will still prevail.  
I'm just wondering how much of a problem virtual classes are in the plugin, since I've used them heavily there. I don't want to scare away potential contributors, but it seems like virtual classes are considered a bad thing?



On Tue, Jan 27, 2009 at 8:45 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

It would be great if there was an explanation as to what virtual
classes are in the context of scala, perhaps an example or two.  It
keeps getting mentioned as a 2.8.0 thing, although its never explained
further.

On 1/27/09, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:
>
>

On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid wrote:
> I'm just wondering how much of a problem virtual classes are in the plugin,
> since I've used them heavily there. I don't want to scare away potential
> contributors, but it seems like virtual classes are considered a bad thing?

Just to clarify. The issue isn't virtual classes per se, but rather
the way that virtual classes are currently simulated in the Eclipse
plugin and whether or not that encoding gets in the way of
comprehension of the plugin code generally.

A supplementary question is whether the abstraction layer this virtual
class simulation provides (abstracting the from the Eclipse filesystem
interface in ... err ... the Eclipse plugin?) is necessary at all even
if it were to be rejigged in terms of first-class language support for
virtual classes (IMO, it's not necessary at all).

The issue definitely *isn't* "virtual classes, good or bad" ...

Cheers,

Miles

A 2-page description of the virtual class emulation pattern as it is
used in the plugin would go a long way toward clarifying this
discussion.

Just my 2 cents.

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

On Tue, Jan 27, 2009 at 11:38 AM, Miles Sabin wrote:
> On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid wrote:
>> I'm just wondering how much of a problem virtual classes are in the plugin,
>> since I've used them heavily there. I don't want to scare away potential
>> contributors, but it seems like virtual classes are considered a bad thing?
>
> Just to clarify. The issue isn't virtual classes per se, but rather
> the way that virtual classes are currently simulated in the Eclipse
> plugin and whether or not that encoding gets in the way of
> comprehension of the plugin code generally.
>
> A supplementary question is whether the abstraction layer this virtual
> class simulation provides (abstracting the from the Eclipse filesystem
> interface in ... err ... the Eclipse plugin?) is necessary at all even
> if it were to be rejigged in terms of first-class language support for
> virtual classes (IMO, it's not necessary at all).
>
> The issue definitely *isn't* "virtual classes, good or bad" ...
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)1273 720 779
> mobile: +44 (0)7813 944 528
> skype: milessabin
>

I'm a big fan of KISS... don't abstract unless you know it's necessary.   Are any other plugins using this code?  I'm pretty sure the answer is no, and therefore you should keep a simple (but robust) design.  I must say my first reaction to the eclipe plugin code was "DAMN!", but eventually I overcame and started hacking.  That being said, if you (Sean) are willing to document your use of virtual classes and lay out the design for contributors, then I'm willing to learn and utilize it.  However coming from a Java-only background... the plugin currently takes some time to grok.

-Josh

On Tue, Jan 27, 2009 at 8:38 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:
> I'm just wondering how much of a problem virtual classes are in the plugin,
> since I've used them heavily there. I don't want to scare away potential
> contributors, but it seems like virtual classes are considered a bad thing?

Just to clarify. The issue isn't virtual classes per se, but rather
the way that virtual classes are currently simulated in the Eclipse
plugin and whether or not that encoding gets in the way of
comprehension of the plugin code generally.

A supplementary question is whether the abstraction layer this virtual
class simulation provides (abstracting the from the Eclipse filesystem
interface in ... err ... the Eclipse plugin?) is necessary at all even
if it were to be rejigged in terms of first-class language support for
virtual classes (IMO, it's not necessary at all).

The issue definitely *isn't* "virtual classes, good or bad" ...

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

Unfortunately, when you are given multiple complex systems, you are stuck in a big hole and have to start digging out. Dealing with one part of the system at a time really helps out, and allows for progress, even if the abstraction is unnecessary from a reuse perspective. This is the biggest misconception about abstraction: it is just as well used as a tool to conceptually decompose problems as it is used to reuse solutions. Sometimes over-abstraction occurs because the problem was really complicated and/or poorly understood, and to make progress you just start layering (hey, if you don't know how much material to use in building a bridge, you just overbuild!). If the problem and systems are well understood, efficiency leads to fewer abstractions (as they ultimately get in the way). 
I'm definitely willing to document the design, the virtual class pattern used in the plugin is very systematic. I'll try to write something over the CNY holiday (still a few days left at anyrate). 
Sean


On Tue, Jan 27, 2009 at 10:34 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm a big fan of KISS... don't abstract unless you know it's necessary.   Are any other plugins using this code?  I'm pretty sure the answer is no, and therefore you should keep a simple (but robust) design.  I must say my first reaction to the eclipe plugin code was "DAMN!", but eventually I overcame and started hacking.  That being said, if you (Sean) are willing to document your use of virtual classes and lay out the design for contributors, then I'm willing to learn and utilize it.  However coming from a Java-only background... the plugin currently takes some time to grok.

-Josh

On Tue, Jan 27, 2009 at 8:38 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:
> I'm just wondering how much of a problem virtual classes are in the plugin,
> since I've used them heavily there. I don't want to scare away potential
> contributors, but it seems like virtual classes are considered a bad thing?

Just to clarify. The issue isn't virtual classes per se, but rather
the way that virtual classes are currently simulated in the Eclipse
plugin and whether or not that encoding gets in the way of
comprehension of the plugin code generally.

A supplementary question is whether the abstraction layer this virtual
class simulation provides (abstracting the from the Eclipse filesystem
interface in ... err ... the Eclipse plugin?) is necessary at all even
if it were to be rejigged in terms of first-class language support for
virtual classes (IMO, it's not necessary at all).

The issue definitely *isn't* "virtual classes, good or bad" ...

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

Sean McDirmid wrote:
> I'm not sure if language support is so relevant.

It actually is an issue because the plugin violates the recently added
type volatility checks. Therefore, the plugin only compiles at present
because of a special annotations that was added for the sole purpose of
allowing the Eclipse plugin to compile. Therefore, in the long term the
Eclipse plugin either needs to use the language provided virtual class
support or stop using the existing virtual class pattern.

Code is fluid.  You can add and remove abstraction as it helps or hinders.  Reality does like to get in the way of that slightly, which is why we're constantly fighting it.

2009/1/27 Sean McDirmid <sean.mcdirmid@gmail.com>

Unfortunately, when you are given multiple complex systems, you are stuck in a big hole and have to start digging out. Dealing with one part of the system at a time really helps out, and allows for progress, even if the abstraction is unnecessary from a reuse perspective. This is the biggest misconception about abstraction: it is just as well used as a tool to conceptually decompose problems as it is used to reuse solutions. Sometimes over-abstraction occurs because the problem was really complicated and/or poorly understood, and to make progress you just start layering (hey, if you don't know how much material to use in building a bridge, you just overbuild!). If the problem and systems are well understood, efficiency leads to fewer abstractions (as they ultimately get in the way). 
I'm definitely willing to document the design, the virtual class pattern used in the plugin is very systematic. I'll try to write something over the CNY holiday (still a few days left at anyrate). 
Sean


On Tue, Jan 27, 2009 at 10:34 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm a big fan of KISS... don't abstract unless you know it's necessary.   Are any other plugins using this code?  I'm pretty sure the answer is no, and therefore you should keep a simple (but robust) design.  I must say my first reaction to the eclipe plugin code was "DAMN!", but eventually I overcame and started hacking.  That being said, if you (Sean) are willing to document your use of virtual classes and lay out the design for contributors, then I'm willing to learn and utilize it.  However coming from a Java-only background... the plugin currently takes some time to grok.

-Josh

On Tue, Jan 27, 2009 at 8:38 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:
> I'm just wondering how much of a problem virtual classes are in the plugin,
> since I've used them heavily there. I don't want to scare away potential
> contributors, but it seems like virtual classes are considered a bad thing?

Just to clarify. The issue isn't virtual classes per se, but rather
the way that virtual classes are currently simulated in the Eclipse
plugin and whether or not that encoding gets in the way of
comprehension of the plugin code generally.

A supplementary question is whether the abstraction layer this virtual
class simulation provides (abstracting the from the Eclipse filesystem
interface in ... err ... the Eclipse plugin?) is necessary at all even
if it were to be rejigged in terms of first-class language support for
virtual classes (IMO, it's not necessary at all).

The issue definitely *isn't* "virtual classes, good or bad" ...

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

As far as I understand, the virtual class support added to Scala is not as expressive as the pattern so there is no point in migrating to it. I'm completely willing to move to it if its not neutered too much. 
As for the volatility checks: its valid yesterday, invalid today, maybe valid tomorrow. Yesterday is history, Tomorrow is a mystery, ...


On Tue, Jan 27, 2009 at 11:00 PM, Geoffrey Alan Washburn <geoffrey.washburn@epfl.ch> wrote:

Sean McDirmid wrote:

I'm not sure if language support is so relevant.

It actually is an issue because the plugin violates the recently added type volatility checks.  Therefore, the plugin only compiles at present because of a special annotations that was added for the sole purpose of allowing the Eclipse plugin to compile.  Therefore, in the long term the Eclipse plugin either needs to use the language provided virtual class support or stop using the existing virtual class pattern.

Sean McDirmid wrote:

> As for the volatility checks: its valid yesterday, invalid today, maybe
> valid tomorrow. Yesterday is history, Tomorrow is a mystery, ....

Sean, the code will never become valid again. Type safety doesn't work
that way, and it would require ridiculous amounts of program analysis to
show that, even though it violates these constraints, your code is
correct as is, assuming that it really is correct. I've already found
examples where the current volatility checks are not enough to rule out
programs that violate type safety. Given that the Eclipse compiler is
apparently the only Scala code in existence that violates these
constraints (no one complained when 2.7.3 was released), I do not expect
that the Scala compiler will continue to provide an escape hatch solely
for the Eclipse plugin. So it would be best to invest in rewriting the
code sooner rather than later.

On Tue, Jan 27, 2009 at 3:26 PM, Geoffrey Alan Washburn
wrote:
> Given that the Eclipse compiler is apparently the only Scala code in existence
> that violates these constraints (no one complained when 2.7.3 was released), I
> do not expect that the Scala compiler will continue to provide an escape hatch
> solely for the Eclipse plugin. So it would be best to invest in rewriting the
> code sooner rather than later.

That looks like a compelling argument ...

Do I have any volunteers to help with this (ie. removing the
virtual-class base filesystem abstraction layer from the plugin)?

Failing that, if I were to do it, would that encourage more people to
contribute (or contribute more) to the plugin?

Cheers,

Miles

Geoffrey Alan Washburn wrote:
> Sean McDirmid wrote:
>
> Given that the Eclipse compiler is
> apparently the only Scala code in existence that violates these
> constraints (no one complained when 2.7.3 was released),

I need them too, do you remember?

Ingo

Its not a compelling argument. Some hypothetical attack where no example attack has ever been constructed... 
Where is Scala going? Is it towards pragmatism or proven type safety lala land where the language is type safe but otherwise unusable (doesn't Haskell already occupy this niche?). I really hate languages where I need a PhD in type theory to even understand the rules. 
But if thats what you want to do, just change it. I'm out. 
On Tue, Jan 27, 2009 at 11:41 PM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 3:26 PM, Geoffrey Alan Washburn
<geoffrey.washburn@epfl.ch> wrote:
> Given that the Eclipse compiler is apparently the only Scala code in existence
> that violates these constraints (no one complained when 2.7.3 was released), I
> do not expect that the Scala compiler will continue to provide an escape hatch
> solely for the Eclipse plugin.  So it would be best to invest in rewriting the
> code sooner rather than later.

That looks like a compelling argument ...

Do I have any volunteers to help with this (ie. removing the
virtual-class base filesystem abstraction layer from the plugin)?

Failing that, if I were to do it, would that encourage more people to
contribute (or contribute more) to the plugin?

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

On Tue, Jan 27, 2009 at 4:26 PM, Geoffrey Alan Washburn
wrote:
> Sean McDirmid wrote:
>
>
>> As for the volatility checks: its valid yesterday, invalid today, maybe
>> valid tomorrow. Yesterday is history, Tomorrow is a mystery, ....
>
> Sean, the code will never become valid again. Type safety doesn't work that
> way, and it would require ridiculous amounts of program analysis to show
> that, even though it violates these constraints, your code is correct as is,
> assuming that it really is correct. I've already found examples where the
> current volatility checks are not enough to rule out programs that violate
> type safety. Given that the Eclipse compiler is apparently the only Scala
> code in existence that violates these constraints (no one complained when
> 2.7.3 was released), I do not expect that the Scala compiler will continue
> to provide an escape hatch solely for the Eclipse plugin. So it would be
> best to invest in rewriting the code sooner rather than later.
>
I agree that this coding pattern is very uncommon. But we have not
decided to remove the uncheckedStable annotations which make it work.
In fact, I tend towards keeping them around in case other people run
into the same problems. They might also be useful internally to flag
the output of a true virtual class transformation as safe. So there's
no immediate pressure to rewrite Sean's encoding from that
perspective.

Cheers

Sean McDirmid wrote:
> Its not a compelling argument. Some hypothetical attack where no example
> attack has ever been constructed...

These are not "hypothetical" attacks. There are programs in the Scala
tests directory that illustrate the issue and there are open tickets
that show additional ways to violate type safety in actual programs.

> Where is Scala going? Is it towards pragmatism or proven type safety
> lala land where the language is type safe but otherwise unusable
> (doesn't Haskell already occupy this niche?). I really hate languages
> where I need a PhD in type theory to even understand the rules.

The rules in this case are rather simple.

On Tue, Jan 27, 2009 at 3:47 PM, Christos KK Loverdos
wrote:
> Another 2 cents from me.
> Either someone explain this thing, preferable to a page in the Scala web
> site, so that it is settled once and for all (virtual classes have been in
> past threads) or at least someone give a couple of svn pointers to Eclipse
> plugin source code, where this pattern appears. I am certain that, in the
> second case, a lot of people could figure out just by code-reading.

Sure.

Start from here,

https://lampsvn.epfl.ch/trac/scala/browser/scala-plugin/trunk/src/lampio...

and see if you can work out where the types defined here get
associated with Eclipse IFiles and IProjects.

Cheers,

Miles

Another 2 cents from me.
Either someone explain this thing, preferable to a page in the Scala web site, so that it is settled once and for all (virtual classes have been in past threads) or at least someone give a couple of svn pointers to Eclipse plugin source code, where this pattern appears. I am certain that, in the second case, a lot of people could figure out just by code-reading.
BRChristos.

On Tue, Jan 27, 2009 at 4:30 PM, Rafael de F. Ferreira <rafaeldff@gmail.com> wrote:

A 2-page description of the virtual class emulation pattern as it is
used in the plugin would go a long way toward clarifying this
discussion.

Just my 2 cents.

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/



On Tue, Jan 27, 2009 at 11:38 AM, Miles Sabin <miles@milessabin.com> wrote:
> On Tue, Jan 27, 2009 at 1:09 PM, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:
>> I'm just wondering how much of a problem virtual classes are in the plugin,
>> since I've used them heavily there. I don't want to scare away potential
>> contributors, but it seems like virtual classes are considered a bad thing?
>
> Just to clarify. The issue isn't virtual classes per se, but rather
> the way that virtual classes are currently simulated in the Eclipse
> plugin and whether or not that encoding gets in the way of
> comprehension of the plugin code generally.
>
> A supplementary question is whether the abstraction layer this virtual
> class simulation provides (abstracting the from the Eclipse filesystem
> interface in ... err ... the Eclipse plugin?) is necessary at all even
> if it were to be rejigged in terms of first-class language support for
> virtual classes (IMO, it's not necessary at all).
>
> The issue definitely *isn't* "virtual classes, good or bad" ...
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel:    +44 (0)1273 720 779
> mobile: +44 (0)7813 944 528
> skype:  milessabin
>

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Is pragmatism where the syntax is exactly the same as Java's?

if ["$PRAGMATIC"];
    ln -s `which javac` /usr/local/bin/scalac
fi

Haskell isn't unusable without a PhD in type theory.  At least one of the xmonad maintainers doesn't understand monads, for example, but clearly gets useful stuff done in Haskell.

2009/1/27 Sean McDirmid <sean.mcdirmid@gmail.com>

Its not a compelling argument. Some hypothetical attack where no example attack has ever been constructed... 
Where is Scala going? Is it towards pragmatism or proven type safety lala land where the language is type safe but otherwise unusable (doesn't Haskell already occupy this niche?). I really hate languages where I need a PhD in type theory to even understand the rules. 
But if thats what you want to do, just change it. I'm out. 
On Tue, Jan 27, 2009 at 11:41 PM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 3:26 PM, Geoffrey Alan Washburn
<geoffrey.washburn@epfl.ch> wrote:
> Given that the Eclipse compiler is apparently the only Scala code in existence
> that violates these constraints (no one complained when 2.7.3 was released), I
> do not expect that the Scala compiler will continue to provide an escape hatch
> solely for the Eclipse plugin.  So it would be best to invest in rewriting the
> code sooner rather than later.

That looks like a compelling argument ...

Do I have any volunteers to help with this (ie. removing the
virtual-class base filesystem abstraction layer from the plugin)?

Failing that, if I were to do it, would that encourage more people to
contribute (or contribute more) to the plugin?

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

OK. sorry, I've got enough dynamic casts in my code that these issues just become noise. But if Scala removes my dynamic casts, or even my ability to cast null to a type parameter type (yep, do it all the time), or annotations that allow me to ignore certain checks, I quickly lose the ability to write any useful code. I hope the philosophy of "not shoving checks down our throats" continues. 
I want static type safety..except when I don't want it.
On Tue, Jan 27, 2009 at 11:55 PM, Geoffrey Alan Washburn <geoffrey.washburn@epfl.ch> wrote:

Sean McDirmid wrote:

Its not a compelling argument. Some hypothetical attack where no example attack has ever been constructed...

These are not "hypothetical" attacks.  There are programs in the Scala tests directory that illustrate the issue and there are open tickets that show additional ways to violate type safety in actual programs.

Where is Scala going? Is it towards pragmatism or proven type safety lala land where the language is type safe but otherwise unusable (doesn't Haskell already occupy this niche?). I really hate languages where I need a PhD in type theory to even understand the rules.

The rules in this case are rather simple.

Ingo Maier wrote:
> Geoffrey Alan Washburn wrote:
>> Sean McDirmid wrote:
>>
>> Given that the Eclipse compiler is apparently the only Scala code in
>> existence that violates these constraints (no one complained when
>> 2.7.3 was released),
>
> I need them too, do you remember?

The idea would be to switch to the language provided virtual classes
when they become available.

martin odersky wrote:

> I agree that this coding pattern is very uncommon. But we have not
> decided to remove the uncheckedStable annotations which make it work.

Last time it was discussed my understanding was that we would remove it
after language support for virtual classes is added.

> In fact, I tend towards keeping them around in case other people run
> into the same problems.

I think it would be better to encourage them to use the language
provided virtual classes which will perform the necessary rechecking to
ensure safety.

That's at least something.
Thanx!

On Tue, Jan 27, 2009 at 5:56 PM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Jan 27, 2009 at 3:47 PM, Christos KK Loverdos
<loverdos@gmail.com> wrote:
> Another 2 cents from me.
> Either someone explain this thing, preferable to a page in the Scala web
> site, so that it is settled once and for all (virtual classes have been in
> past threads) or at least someone give a couple of svn pointers to Eclipse
> plugin source code, where this pattern appears. I am certain that, in the
> second case, a lot of people could figure out just by code-reading.

Sure.

Start from here,

 https://lampsvn.epfl.ch/trac/scala/browser/scala-plugin/trunk/src/lampion/core/Plugin.scala?order=date&desc=1

and see if you can work out where the types defined here get
associated with Eclipse IFiles and IProjects.

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Geoffrey Alan Washburn wrote:

>> Where is Scala going? Is it towards pragmatism or proven type safety
>> lala land where the language is type safe but otherwise unusable
>> (doesn't Haskell already occupy this niche?). I really hate languages
>> where I need a PhD in type theory to even understand the rules.
>
> The rules in this case are rather simple.

After further investigation, I will concede that despite being simple
enough to understand they are apparently not documented anywhere other
than the compiler implementation. I could swear I saw Martin updating
the text of the SLS, but maybe he hasn't committed those changes yet.

Geoffrey Alan Washburn wrote:
> Ingo Maier wrote:
>> Geoffrey Alan Washburn wrote:
>>> Sean McDirmid wrote:
>>>
>>> Given that the Eclipse compiler is apparently the only Scala code in
>>> existence that violates these constraints (no one complained when
>>> 2.7.3 was released),
>> I need them too, do you remember?
>
> The idea would be to switch to the language provided virtual classes
> when they become available.
>

I don't see much of a difference here. It's not clear whether the plugin
cannot be adapted to the foreseeable compiler encoding. There is no
immediate urge to remove the checks, neither for me nor for them.

Ingo

On Tue, Jan 27, 2009 at 2:54 PM, Sean McDirmid wrote:
> I'm definitely willing to document the design, the virtual class pattern
> used in the plugin is very systematic. I'll try to write something over the
> CNY holiday (still a few days left at anyrate).

If you have _any_ time for documentation the thing that would be of
most value is documentation of scalac's IDE support API ... if nothing
else, this would benefit the Netbeans and probably the IntelliJ
plugins as well.

Cheers,

Miles

Ingo Maier wrote:

> I don't see much of a difference here. It's not clear whether the plugin
> cannot be adapted to the foreseeable compiler encoding. There is no
> immediate urge to remove the checks,

Because bad habits are generally supposed to be discouraged? It seems
like we as the developers of Scala should be trying to set a good
example in terms of coding style.

I am not sure why the checks were put in place if we don't plan to
enforce them. And if the virtual class support is too weak to be useful
to anyone perhaps we should be rethinking whether it is worthwhile time
investment.

Here comes the pdf of the updated SLS.

martin odersky wrote:
> Here comes the pdf of the updated SLS.

We should probably also refresh the version on the website before too long.

Geoffrey Alan Washburn wrote:
> Ingo Maier wrote:
>
>> I don't see much of a difference here. It's not clear whether the plugin
>> cannot be adapted to the foreseeable compiler encoding. There is no
>> immediate urge to remove the checks,
>
> Because bad habits are generally supposed to be discouraged? It seems
> like we as the developers of Scala should be trying to set a good
> example in terms of coding style.

The virtual class encodings need uncheckedStable. You know that.

>
> I am not sure why the checks were put in place if we don't plan to
> enforce them. And if the virtual class support is too weak to be useful
> to anyone perhaps we should be rethinking whether it is worthwhile time
> investment.
>

I'd appreciate if you could not lapse into premature generalization. Thanks.

Ingo

I noted that I had indeed not checked in the changes to the SLS
regarding volatile types. I have done so now, and also append the pdf
directly.

Note section 3.6 on page 33 on volatile types and page 127 on the
uncheckedStable annotation.

On Tue, Jan 27, 2009 at 6:23 PM, Geoffrey Alan Washburn
wrote:
> Ingo Maier wrote:
>
>> I don't see much of a difference here. It's not clear whether the plugin
>> cannot be adapted to the foreseeable compiler encoding. There is no
>> immediate urge to remove the checks,
>
> Because bad habits are generally supposed to be discouraged? It seems like
> we as the developers of Scala should be trying to set a good example in
> terms of coding style.
>
I am a firm believer in the ability to override static type tests
where necessary. For normal type conformance there are casts (or typed
pattern matches). That's a good thing IMO. For other kinds of type
errors (variance violations, volatility) there should be similar means
to override a type system. We know that every type system will reject
some perfectly sensible programs. That's no problem as long as we can
override it (with as much syntactic overhead as necessary, I don't
want to make these things silent).

Cheers

Ingo Maier wrote:
>> Because bad habits are generally supposed to be discouraged? It seems
>> like we as the developers of Scala should be trying to set a good
>> example in terms of coding style.
>
> The virtual class encodings need uncheckedStable. You know that.

If devirtualization happens after typechecking I wouldn't think it
should be necessary.

>> I am not sure why the checks were put in place if we don't plan to
>> enforce them. And if the virtual class support is too weak to be
>> useful to anyone perhaps we should be rethinking whether it is
>> worthwhile time investment.
>>
>
> I'd appreciate if you could not lapse into premature generalization.
> Thanks.

Then why has it come up twice in this thread that the proposed virtual
class extension is unlikely to be good enough for real-world usage? I'm
serious, if people are going to keep on manually encoding virtual
classes anyway, maybe we need to step back and rethink it.

Geoffrey Alan Washburn wrote:
>
> Then why has it come up twice in this thread that the proposed virtual
> class extension is unlikely to be good enough for real-world usage?

Then I missed something. Who said this and where? I only read about
Sean's statement that he is willing to use it, if it doesn't restrict
him too much.

Ingo

Geoffrey Alan Washburn wrote:

> Then why has it come up twice in this thread that the proposed virtual
> class extension is unlikely to be good enough for real-world usage? I'm
> serious, if people are going to keep on manually encoding virtual
> classes anyway, maybe we need to step back and rethink it.

Let me put it this way. What I am hearing, particularly from Sean, is
that there is some thing X (perhaps several things) that the proposed
virtual class extension won't let programmers do that they really need
to be able to do. Therefore, it is worrisome from the perspective of
someone wanting to adopt the shiny new support for virtual classes if
they start using it and down the line find that they really want X, and
that their only recourse is to take all their code and rewrite it to use
a manual encoding of virtual classes.

Admittedly no abstraction is perfect, but if we know going in that this
is going to happen then maybe we should address it now.

Is there a virtual classes SIP lingering out there somewhere?

On Tue, Jan 27, 2009 at 2:03 PM, Geoffrey Alan Washburn <geoffrey.washburn@epfl.ch> wrote:

Geoffrey Alan Washburn wrote:

Then why has it come up twice in this thread that the proposed virtual class extension is unlikely to be good enough for real-world usage?  I'm serious, if people are going to keep on manually encoding virtual classes anyway, maybe we need to step back and rethink it.

Let me put it this way.  What I am hearing, particularly from Sean, is that there is some thing X (perhaps several things) that the proposed virtual class extension won't let programmers do that they really need to be able to do.  Therefore, it is worrisome from the perspective of someone wanting to adopt the shiny new support for virtual classes if they start using it and down the line find that they really want X, and that their only recourse is to take all their code and rewrite it to use a manual encoding of virtual classes.

Admittedly no abstraction is perfect, but if we know going in that this is going to happen then maybe we should address it now.

--
http://erikengbrecht.blogspot.com/

Geoffrey Alan Washburn wrote:
> Geoffrey Alan Washburn wrote:
>
>> Then why has it come up twice in this thread that the proposed virtual
>> class extension is unlikely to be good enough for real-world usage?
>> I'm serious, if people are going to keep on manually encoding virtual
>> classes anyway, maybe we need to step back and rethink it.
>
> Let me put it this way. What I am hearing, particularly from Sean, is
> that there is some thing X (perhaps several things) that the proposed
> virtual class extension won't let programmers do that they really need
> to be able to do. Therefore, it is worrisome from the perspective of
> someone wanting to adopt the shiny new support for virtual classes if
> they start using it and down the line find that they really want X, and
> that their only recourse is to take all their code and rewrite it to use
> a manual encoding of virtual classes.
>
> Admittedly no abstraction is perfect, but if we know going in that this
> is going to happen then maybe we should address it now.
>

I think you are interpreting too much into Sean's statements but I'd
like to hear from him what the worrisome points would be.

Ingo

https://lampsvn.epfl.ch/trac/scala/browser/lamp-sip/virtual-traits

Erik Engbrecht wrote:
> Is there a virtual classes SIP lingering out there somewhere?
>
> On Tue, Jan 27, 2009 at 2:03 PM, Geoffrey Alan Washburn
> wrote:
>
> Geoffrey Alan Washburn wrote:
>
> Then why has it come up twice in this thread that the proposed
> virtual class extension is unlikely to be good enough for
> real-world usage? I'm serious, if people are going to keep on
> manually encoding virtual classes anyway, maybe we need to step
> back and rethink it.
>
>
> Let me put it this way. What I am hearing, particularly from Sean,
> is that there is some thing X (perhaps several things) that the
> proposed virtual class extension won't let programmers do that they
> really need to be able to do. Therefore, it is worrisome from the
> perspective of someone wanting to adopt the shiny new support for
> virtual classes if they start using it and down the line find that
> they really want X, and that their only recourse is to take all
> their code and rewrite it to use a manual encoding of virtual classes.
>
> Admittedly no abstraction is perfect, but if we know going in that
> this is going to happen then maybe we should address it now.
>
>
>
>
>

Beautiful!   So anyone with concerns about virtual traits should be providing feedback on the SIP.

On Tue, Jan 27, 2009 at 2:13 PM, Ingo Maier <ingo.maier@epfl.ch> wrote:

https://lampsvn.epfl.ch/trac/scala/browser/lamp-sip/virtual-traits

Erik Engbrecht wrote:

Is there a virtual classes SIP lingering out there somewhere?

On Tue, Jan 27, 2009 at 2:03 PM, Geoffrey Alan Washburn <geoffrey.washburn@epfl.ch> wrote:

   Geoffrey Alan Washburn wrote:

       Then why has it come up twice in this thread that the proposed
       virtual class extension is unlikely to be good enough for
       real-world usage?  I'm serious, if people are going to keep on
       manually encoding virtual classes anyway, maybe we need to step
       back and rethink it.


   Let me put it this way.  What I am hearing, particularly from Sean,
   is that there is some thing X (perhaps several things) that the
   proposed virtual class extension won't let programmers do that they
   really need to be able to do.  Therefore, it is worrisome from the
   perspective of someone wanting to adopt the shiny new support for
   virtual classes if they start using it and down the line find that
   they really want X, and that their only recourse is to take all
   their code and rewrite it to use a manual encoding of virtual classes.

   Admittedly no abstraction is perfect, but if we know going in that
   this is going to happen then maybe we should address it now.





--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

Ingo Maier wrote:
> Geoffrey Alan Washburn wrote:
>>
>> Then why has it come up twice in this thread that the proposed virtual
>> class extension is unlikely to be good enough for real-world usage?
>
> Then I missed something. Who said this and where? I only read about
> Sean's statement that he is willing to use it, if it doesn't restrict
> him too much.

But Sean also said: "As far as I understand, the virtual class support
added to Scala is not as expressive as the pattern so there is no point
in migrating to it."

I guess I also received very strongly the impression that switching to
the proposed virtual class extension was not a good enough alternative
to @uncheckedStable, because there were still things that could not be
done otherwise. And if we still need to do these things then, maybe we
need to rethink what the virtual class extension needs to be able to do.

martin odersky wrote:

> I am a firm believer in the ability to override static type tests
> where necessary. For normal type conformance there are casts (or typed
> pattern matches). That's a good thing IMO. For other kinds of type
> errors (variance violations, volatility) there should be similar means
> to override a type system. We know that every type system will reject
> some perfectly sensible programs. That's no problem as long as we can
> override it (with as much syntactic overhead as necessary, I don't
> want to make these things silent).

I can see where you are coming from, but to me, adding this particular
escape hatch doesn't seem consistent with our overall position on type
safety. We've gotten far more complaints on the mailing lists from
people about not being able to override type aliases than we have ever
received about volatility, but we haven't added an escape hatch for
those people yet.

thanks that clears it up nicely. Virtual inheritance for those of us
with C++ damaged brains.

As to the discussion, I've written a fair chunk of code that uses
virtual inheritence so I'm all for it. Its rare that I've needed it,
but when I have its been the best solution.

Also for anyone who is searching for this and the record / case class
field update / virtual constructor stuff, virtual classes don't solve
anything related to it. (I'd asked aloud if they would help but they
won't)

On 1/27/09, Ingo Maier wrote:
> https://lampsvn.epfl.ch/trac/scala/browser/lamp-sip/virtual-traits
>
>
> Erik Engbrecht wrote:
>
> > Is there a virtual classes SIP lingering out there somewhere?
> >
> > On Tue, Jan 27, 2009 at 2:03 PM, Geoffrey Alan Washburn
> wrote:
> >
> > Geoffrey Alan Washburn wrote:
> >
> > Then why has it come up twice in this thread that the proposed
> > virtual class extension is unlikely to be good enough for
> > real-world usage? I'm serious, if people are going to keep on
> > manually encoding virtual classes anyway, maybe we need to step
> > back and rethink it.
> >
> >
> > Let me put it this way. What I am hearing, particularly from Sean,
> > is that there is some thing X (perhaps several things) that the
> > proposed virtual class extension won't let programmers do that they
> > really need to be able to do. Therefore, it is worrisome from the
> > perspective of someone wanting to adopt the shiny new support for
> > virtual classes if they start using it and down the line find that
> > they really want X, and that their only recourse is to take all
> > their code and rewrite it to use a manual encoding of virtual classes.
> >
> > Admittedly no abstraction is perfect, but if we know going in that
> > this is going to happen then maybe we should address it now.
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
> >
>
>

Geoffrey Alan Washburn wrote:
> martin odersky wrote:
>> Here comes the pdf of the updated SLS.
>
> We should probably also refresh the version on the website before too long.

The documentation is always updated as part of the release process, the new
version will come online in any case when the next version is released
(2.7.4 or 2.8.0, whichever comes first).
Toni

Antonio Cunei wrote:
> Geoffrey Alan Washburn wrote:
>> martin odersky wrote:
>>> Here comes the pdf of the updated SLS.
>>
>> We should probably also refresh the version on the website before too
>> long.
>
> The documentation is always updated as part of the release process, the
> new version will come online in any case when the next version is
> released (2.7.4 or 2.8.0, whichever comes first).

Right, except that theses changes in the documentation should have been
part of the 2.7.3 release. Still I suppose if it someone really does
need to know about these changes before 2.7.4 or 2.8.0 are released,
they will just ask on one of the mailing lists.

> I can see where you are coming from, but to me, adding this particular
> escape hatch doesn't seem consistent with our overall position on type
> safety. We've gotten far more complaints on the mailing lists from people
> about not being able to override type aliases than we have ever received
> about volatility, but we haven't added an escape hatch for those people yet.
>
Well, maybe we should do that, then!. I think an escape hatch is
warranted once someone has demonstrated a use case where a program
pattern is useful and safe yet the static type system prevents it, and
no practical workarounds exist. @uncheckedStable supports the virtual
class encoding. I have recently come to appreciate that we need escape
hatches for variance annotations as well. If someone shows a use case
where overriding type aliases is safe and no good workaround exists
otherwise, I'm all in favor of adding an escape hatch.

Cheers

Hey Geoffrey,
I haven't seen your recent proposed virtual class extension, it might work out or it might not. I remember some restrictions in early proposals where most of my code couldn't be re-encoded in the new proposal. I also think its doubtful you'll be able to make everyone happy with your extension (every high-level abstraction will have its limitations). If the extension was available when the code was initially written, things might be different, but now with all the existing code that we would have to port to a new scheme...
I'd like to think of the IDE as an example where virtual classes are used successfully, and this is not the first time I've used this pattern (actually, this is a variation of the open class pattern that we used in Jiazzi). In that case, it gives you an example to work with in your design, but of course there are other examples and use cases. 
The nice thing...or what used to be a nice thing, about Scala, was its power: actually virtual classes aren't so necessary because you can encode them manually with not so much effort. If the low level plumbing is getting nerfed, and we have to rely more on high-level constructs, then of course, the language will be more limited (if easier to use). 

On Wed, Jan 28, 2009 at 2:39 AM, Geoffrey Alan Washburn <geoffrey.washburn@epfl.ch> wrote:

Then why has it come up twice in this thread that the proposed virtual class extension is unlikely to be good enough for real-world usage?  I'm serious, if people are going to keep on manually encoding virtual classes anyway, maybe we need to step back and rethink it.

This is a huge task. To understand the scalac's IDE support, you really have to understand scalac. Caoyuan has hacked into scalac by hacking Global (just like me) but in a way that grows his own IDE support. The IntelliJ people have their own infrastructure and won't go near Scalac (instead, they are trying to re-implement all of Scalac's rules). 
I guess I could write the following document:(1) The plugin's architecture as it stands today. Talk a bit about how it is divided into multiple layers via virtual class encoding.
(2) High-level overview of incremental compilation in its three phases lex, parse, type check.
(3) More about type checking.
But note all the big problems in the plugin right now are mostly unrelated to the scalac part. Its mostly the way we are hooked into Eclipse's editor interface. There are problems in the type checker (mostly related to case classes), but these aren't the huge crash/re-open/close your project bugs that are occurring because of the Eclipse editor. 
On Wed, Jan 28, 2009 at 12:55 AM, Miles Sabin <miles@milessabin.com> wrote:

If you have _any_ time for documentation the thing that would be of
most value is documentation of scalac's IDE support API ... if nothing
else, this would benefit the Netbeans and probably the IntelliJ
plugins as well.

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

On Wed, Jan 28, 2009 at 1:56 AM, Sean McDirmid wrote:
> I guess I could write the following document:

> (2) High-level overview of incremental compilation in its three phases lex,
> parse, type check.

This would be extremely welcome :-)

Cheers,

Miles