Custom Search
|
Date: August 31, 2005
From: Greg Fitzgerald <garious@xxxxxxxxx>
In-reply-to:
<1125476316.20593.10.camel@xxxxxxxxxxxxxxxx>
References:
<1f3dc80d050830223773d82fb6@xxxxxxxxxxxxxx> <1125476316.20593.10.camel@xxxxxxxxxxxxxxxx>
Hi Greg,
On Tue, 2005-08-30 at 22:37 -0700, Greg Fitzgerald wrote:
> I'm trying to run version 1.0.2 of the Scala Eclipse plugin with
> Eclipse 3.1, Scala 1.4.0.0 and JDK 1.5 . When I go to add a 'New
> Object,' the wizard won't enable the 'finish' button. Any idea why?
I think this problem has been reported before on this mailing list. I
include here the reply at that time.
====================================================================
Related to your problem, it seems to be a CLASSPATH problem. I
reproduced your problem and I inspected the log file of eclipse (under
workspace/.metadata/.log) and it seemed the plugin could not find
scala.ScalaObject. This is due to the fact that version 1.4 of scala
changed the directory structure to become more *NIX standard, and the
lib/ directory (containing scala.jar et al) is no more where it was.
Therefore, if you have scala 1.3.x.x it should work, but if you have the
latest scala 1.4, you should change your scala home location under
"Window/Preferences"/Scala tab by appending "share/scala- 1.4.0.0" your
scala installation directory. The directory you pass there should
contain a "lib/" sub-directory with all the jars. I also noticed that
sometime this does not help unless Eclipse is restarted.
======================================================================
Hope this helps,
Iulian
Date: August 31, 2005
From: Iulian Dragos <iulian.dragos@xxxxxxx>
In-reply-to:
<1f3dc80d050830223773d82fb6@xxxxxxxxxxxxxx>
References:
<1f3dc80d050830223773d82fb6@xxxxxxxxxxxxxx>
Hi Greg, On Tue, 2005-08-30 at 22:37 -0700, Greg Fitzgerald wrote: > I'm trying to run version 1.0.2 of the Scala Eclipse plugin with > Eclipse 3.1, Scala 1.4.0.0 and JDK 1.5. When I go to add a 'New > Object,' the wizard won't enable the 'finish' button. Any idea why? I think this problem has been reported before on this mailing list. I include here the reply at that time. ==================================================================== Related to your problem, it seems to be a CLASSPATH problem. I reproduced your problem and I inspected the log file of eclipse (under workspace/.metadata/.log) and it seemed the plugin could not find scala.ScalaObject. This is due to the fact that version 1.4 of scala changed the directory structure to become more *NIX standard, and the lib/ directory (containing scala.jar et al) is no more where it was. Therefore, if you have scala 1.3.x.x it should work, but if you have the latest scala 1.4, you should change your scala home location under "Window/Preferences"/Scala tab by appending "share/scala-1.4.0.0" your scala installation directory. The directory you pass there should contain a "lib/" sub-directory with all the jars. I also noticed that sometime this does not help unless Eclipse is restarted. ====================================================================== Hope this helps, Iulian
Date: August 31, 2005
From: Greg Fitzgerald <garious@xxxxxxxxx>
Date: August 29, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<1769878784.20050828212550@xxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx> <20050824234239.GC8491@xxxxxxxxxxxxxxxx> <91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx> <1769878784.20050828212550@xxxxxxxxxxx>
hi wayne,
> I don't know about Perl, but this is easy to do in Ruby. In Ruby, a
> call to an undefined method becomes a call to method_missing on the
> same class. So having an object of class A delegate any undefined
> methods to a member which is an object of class B looks like this:
>
> class A
> def initialize
> @b = B.new
> end
>
> def method_missing(sym, *args, &block)
> @b.__send__(sym, *args, &block)
> end
> end
>
> class B
> def foo
> puts "B::foo called"
> end
> end
>
> a = A.new
> a.foo # which prints "B::foo called"
actually you could either use the delegate library in ruby
or at least have a class level statement to create those
method_missing methods.
class Class
# creates a a class method for defining delegates
# on a type base
def delegate(_cls)
class_eval <<-SOURCE
def method_missing(sym, *args, &block)
init
@delegate.__send__(sym, *args, &block)
end
def init
if @delegate == nil
@delegate = #{_cls.name}.new
end
end
SOURCE
end
end
class Foo
def foo1
puts "Foo::foo1"
end
def foo2
puts "Foo::foo2"
end
end
class Bar
delegate Foo
def bar
puts "Bar::bar";
end
def foo2
puts "Bar::foo2"
end
end
Bar.new.bar
Bar.new.foo2
Bar.new.foo1
prints this
Bar::bar
Bar::foo2
Foo::foo1
in anyway this is of course much easier done in ruby than scala
as explicit type info and the compilation step are missing.
i asume something like this could be possible with the announced
macro feature in scala.
btw. is there already anything tangible/planned/readable about macros?
ciao robertj
Date: August 29, 2005
From: Wayne Vucenic <wvucenic@xxxxxxxxxxx>
In-reply-to:
<91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx> <20050824234239.GC8491@xxxxxxxxxxxxxxxx> <91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx>
Hi Raoul,
> The frustration I have with the general claim of "just use
> composition" is that most systems do not have a good way of helping
> me avoid the laborious creation and maintenance of wrapper
> dispatching code... unless you use inheritance...I seem to recall
> that Perl...
I don't know about Perl, but this is easy to do in Ruby. In Ruby, a
call to an undefined method becomes a call to method_missing on the
same class. So having an object of class A delegate any undefined
methods to a member which is an object of class B looks like this:
class A
def initialize
@b = B.new
end
def method_missing(sym, *args, &block)
@b.__send__(sym, *args, &block)
end
end
class B
def foo
puts "B::foo called"
end
end
a = A.new
a.foo # which prints "B::foo called"
The argument list to method_missing is first the symbol for the
method (its name), followed by *args which collects a
variable number of arguments into an array, and &block which receives
a block (i.e. closure), if one is associated with this call.
Wayne Vucenic
No Bugs Software
Ruby and C++ Contract Programming in Silicon Valley
Date: August 26, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<20050825193445.GE8491@xxxxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx> <20050824234239.GC8491@xxxxxxxxxxxxxxxx> <91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx> <20050825193445.GE8491@xxxxxxxxxxxxxxxx>
> I agree it's somewhat irritating, but it's just typing; it doesn't > normally actually take long. I suggested a while back that Scala could > have an 'export' statement which would serve this purpose though, > among others. hi Jamie, I'm surprised to hear anybody say that "just typing" is ever OK! :-) > That might sound like a bad thing from a maintenance perspective, but > the advantage is that the compiler will tell you whenever the > delegated interface changes, and you'll have to do something about it. I should think that one could come up with a way of having it in the language, and yet still having warnings generated when appropriate. Explicit versioning of APIs comes to mind. sincerely.
Date: August 25, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx> <20050824234239.GC8491@xxxxxxxxxxxxxxxx> <91a2ba3e05082511287e46d0a@xxxxxxxxxxxxxx>
On Thu, Aug 25, 2005 at 11:28:36AM -0700, Raoul Duke wrote: > The frustrationI have with the general claim of "just use composition" > is that most systems do not have a good way of helping me avoid the > laborious creation and maintenance of wrapper dispatching code... > unless you use inheritance. Java doesn't, C# doesn't as far as I know, > etc. I agree it's somewhat irritating, but it's just typing; it doesn't normally actually take long. I suggested a while back that Scala could have an 'export' statement which would serve this purpose though, among others. Another alternative would be a separate tool that generated delegation methods for a specified interface, for cutting and pasting into code. That might sound like a bad thing from a maintenance perspective, but the advantage is that the compiler will tell you whenever the delegated interface changes, and you'll have to do something about it. -- Jamie Webb
Date: August 25, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<20050824234239.GC8491@xxxxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx> <20050824234239.GC8491@xxxxxxxxxxxxxxxx>
> Best just to avoid that programming style altogether. hi Jamie, The frustrationI have with the general claim of "just use composition" is that most systems do not have a good way of helping me avoid the laborious creation and maintenance of wrapper dispatching code... unless you use inheritance. Java doesn't, C# doesn't as far as I know, etc. I seem to recall that Perl lets you say "if I don't support this method call, then dispatch it to this other thing" but I don't know if it lets you list more than one "other thing". sincerely.
Date: August 25, 2005
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<430D92D3.5010308@xxxxxxxx>
References:
<430D87AF.6010803@xxxxxxxx> <430D909B.4000804@xxxxxxx> <430D92D3.5010308@xxxxxxxx>
robert kuzelj wrote:
This looks like another one of these overloading problems, which hopefully will go away in the next release. It does not hurt to file a bug report though, so that we can make sure the problem is resolved.hi stephane, thanks for the workaround.This looks like a boxing problem. Another candidate for the Scala bugtracking system ?!should i or will you? ciao robertjtest.java (Java 1.4.2_08) --------- public class test { public static void main(String[] args) { java.text.DecimalFormat df = new java.text.DecimalFormat("000"); System.out.println(df.format(new java.lang.Integer(1))); System.out.println(df.format(1)); } } Result: 001 001 test.scala (Scala 1.4.0.0) ---------- object test with Application { val df = new java.text.DecimalFormat("000"); System.out.println(df.format(new java.lang.Integer(1))); System.out.println(df.format(1)); } Result: 001 Exception in thread "main" java.lang.ExceptionInInitializerError at test.main(test.scala:45) Caused by: java.lang.IllegalArgumentException: Cannot format given Object as a Number [..] Bye --Stephane robert kuzelj wrote:hi, i am having problems calling DecimalFormat#format(long). can anybody explain to me what is going on? new DecimalFormat("000").format(1); this gives me the following runtime exception Exception in thread "main" java.lang.IllegalArgumentException: Cannot format given Object as a Number at java.text.DecimalFormat.format(DecimalFormat.java:480) at java.text.Format.format(Format.java:133) i tried a variation of it: new DecimalFormat("000").format(1: long); still the same. another variation i tried is: new DecimalFormat("000").format[long](1); of course that gave me an compile time error. overloaded method format of type (scala.Any,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer <and> (scala.Double,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer <and> (scala.Long,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer <and> (scala.Any)java.lang.String cannot be applied to (scala.Long) any help would be greatly appriciated. ciao robertj
Cheers -- Martin
Date: August 25, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<430D909B.4000804@xxxxxxx>
References:
<430D87AF.6010803@xxxxxxxx> <430D909B.4000804@xxxxxxx>
hi stephane,
thanks for the workaround.
> This looks like a boxing problem.
>
> Another candidate for the Scala bugtracking system ?!
should i or will you?
ciao robertj
>
>
> test.java (Java 1.4.2_08)
> ---------
> public class test {
> public static void main(String[] args) {
> java.text.DecimalFormat df = new java.text.DecimalFormat("000");
> System.out.println(df.format(new java.lang.Integer(1)));
> System.out.println(df.format(1));
> }
> }
>
> Result:
> 001
> 001
>
>
> test.scala (Scala 1.4.0.0)
> ----------
> object test with Application {
> val df = new java.text.DecimalFormat("000");
> System.out.println(df.format(new java.lang.Integer(1)));
> System.out.println(df.format(1));
> }
>
> Result:
> 001
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at test.main(test.scala:45)
> Caused by: java.lang.IllegalArgumentException: Cannot format given
> Object as a Number
> [..]
>
>
> Bye
> --Stephane
>
> robert kuzelj wrote:
>
>> hi,
>>
>> i am having problems calling DecimalFormat#format(long). can anybody
>> explain to me what is going on?
>>
>> new DecimalFormat("000").format(1);
>>
>> this gives me the following runtime exception
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Cannot
>> format given Object as a Number
>> at java.text.DecimalFormat.format(DecimalFormat.java:480)
>> at java.text.Format.format(Format.java:133)
>>
>>
>> i tried a variation of it:
>> new DecimalFormat("000").format(1: long);
>> still the same.
>>
>> another variation i tried is:
>> new DecimalFormat("000").format[long](1);
>> of course that gave me an compile time error.
>>
>> overloaded method format of type
>> (scala.Any,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
>>
>> <and>
>> (scala.Double,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
>>
>> <and>
>> (scala.Long,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
>>
>> <and> (scala.Any)java.lang.String cannot be applied to (scala.Long)
>>
>> any help would be greatly appriciated.
>>
>> ciao robertj
Date: August 25, 2005
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<430D87AF.6010803@xxxxxxxx>
References:
<430D87AF.6010803@xxxxxxxx>
Hi Robert,
On Thu, 2005-08-25 at 10:56 +0200, robert kuzelj wrote:
> i am having problems calling DecimalFormat#format(long). can anybody
> explain to me what is going on?
>
> new DecimalFormat("000").format(1);
>
> this gives me the following runtime exception
>
> Exception in thread "main" java.lang.IllegalArgumentException: Cannot
> format given Object as a Number
> at java.text.DecimalFormat.format(DecimalFormat.java:480)
> at java.text.Format.format(Format.java:133)
The format(long) method is inherited by DecimalFormat from its
superclass - NumberFormat. However, scalac resolves the application to
Format.format(Object) (Format being NumberFormat's superclass). You can
see this from the stack trace but also from the javap disassembly (damn
word-wrap):
13: invokevirtual #26; //Method java/text/Format.format:
(Ljava/lang/Object;)Ljava/lang/String;
I don't know why scalac does that but you can solve the problem by
treating your DecimalFormat instance as NumberFormat instance:
(new DecimalFormat("000"): NumberFormat).format(1)
Cheers
Nikolay
Date: August 25, 2005
From: Stéphane Micheloud <stephane.micheloud@xxxxxxx>
In-reply-to:
<430D87AF.6010803@xxxxxxxx>
References:
<430D87AF.6010803@xxxxxxxx>
Hi Robert,
This looks like a boxing problem.
Another candidate for the Scala bugtracking system ?!
test.java (Java 1.4.2_08)
---------
public class test {
public static void main(String[] args) {
java.text.DecimalFormat df = new java.text.DecimalFormat("000");
System.out.println(df.format(new java.lang.Integer(1)));
System.out.println(df.format(1));
}
}
Result:
001
001
test.scala (Scala 1.4.0.0)
----------
object test with Application {
val df = new java.text.DecimalFormat("000");
System.out.println(df.format(new java.lang.Integer(1)));
System.out.println(df.format(1));
}
Result:
001
Exception in thread "main" java.lang.ExceptionInInitializerError
at test.main(test.scala:45)
Caused by: java.lang.IllegalArgumentException: Cannot format given
Object as a Number
[..] Bye --Stephane robert kuzelj wrote:
hi,
i am having problems calling DecimalFormat#format(long). can anybody
explain to me what is going on?
new DecimalFormat("000").format(1);
this gives me the following runtime exception
Exception in thread "main" java.lang.IllegalArgumentException: Cannot
format given Object as a Number
at java.text.DecimalFormat.format(DecimalFormat.java:480)
at java.text.Format.format(Format.java:133)
i tried a variation of it:
new DecimalFormat("000").format(1: long);
still the same.
another variation i tried is:
new DecimalFormat("000").format[long](1);
of course that gave me an compile time error.
overloaded method format of type
(scala.Any,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and>
(scala.Double,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and>
(scala.Long,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and> (scala.Any)java.lang.String cannot be applied to (scala.Long)
any help would be greatly appriciated.
ciao robertj
Date: August 25, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<1124960496.430d88f03465a@xxxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx> <430C8224.4080106@xxxxxxx> <1124960496.430d88f03465a@xxxxxxxxxxxxxxx>
Quoting burak.emir@xxxxxxx: > > Explicit interface member implementations are flexible, because one can have > things like abstract inheritance "C[X] extends X" (leaving aside that they > are > even harder to implement). If you want to access it as a C, just cast it to > C. Sorry, this should be "one can *in principle* have abstract inheritance", of course C# does not support this. I mentioned this because I remember you mentioning that accidental overrides where also one of the main problems with a.i. cheers Burak
Date: August 25, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<430C8224.4080106@xxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx> <430C8224.4080106@xxxxxxx>
Quoting Martin Odersky <martin.odersky@xxxxxxx>:
> Raoul Duke wrote:
>
> > There's the quintissential 'fragile base class' problem which dogs the
> > use of inheritance. Various folks have proposed ways to work around it
> > (e.g.: selective open recursion from Aldrich). How are / might such
> > things be done in Scala?
>
>
> In a nutshell, the "fragile baseclass problem" means that adding a
> member to a class might break client code that inherits from that class
> and already defines that member (possibly with a different meaning). In
> Java, the member in the client class would override the member in the
> base class, and so lead to incorrect code. Since clients are usually
> unknown, one cannot modify a base class by adding new members in a later
> version without risking to break existing code.
>
BTW, I was pretty surprised of the C# way of avoiding accidental overrides.
You can have "explicit interface implementations" which are used if a method is
called "through that interface". These are defined like private methods only
that the syntax adds the interface to the method identifier. It's so pragmatic
and yet seems very much like right thing. Consider the code at the end(example
changed from Sestoft and Hansen's "C# precisely").
As a consequence, code is more cluttered with casts to interfaces, but being
explicit is not always bad. This is of course a bit contrary to Scala's mixin
approach, where we want mixins to *replace* methods rather than add
alternatives. But the good thing is, you don't have to remember 5 rules that
specify when a class declaration is valid.
Maybe it's a bit misleading that the "new" keyword does not force you to write
an explicit implementation, but probably in most cases it would just be forward
to the hidden one, so that seems fine.
Explicit interface member implementations are flexible, because one can have
things like abstract inheritance "C[X] extends X" (leaving aside that they are
even harder to implement). If you want to access it as a C, just cast it to C.
cheers,
Burak
===
using System;
interface I1 { void M0(); }
interface I2: I1 {
//void M0(); // illegal, "M0 hides I1.M0"
new void M0(); // legal, observe the *new* modifier
int M1();
}
class C: I1, I2 { // in C#, colon means extends
public void M0() { Console.Write("C.M0 "); } // must be here, we implement I1
void I1.M0() { Console.Write("C:I1.M0 "); } // caller thinks, we're I1
//caller sees us as I2. If this wasn't here, then
// the public implementation would be used.
void I2.M0() { Console.Write("C:I2.M0 "); }
// the following meth can only be called if the caller
// casts us to I2.
int I2.M1() { Console.Write("C:I2.M1 "); return 1; }
}
class Test {
public static void Main() {
C c = new C();
c.M0(); ((I1)c).M0(); ((I2)c).M0();
// c.M1(); illegal, "c does not contain definition for M1"
((I2)c).M1();
}
}
===
Date: August 25, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi,
i am having problems calling DecimalFormat#format(long). can anybody
explain to me what is going on?
new DecimalFormat("000").format(1);
this gives me the following runtime exception
Exception in thread "main" java.lang.IllegalArgumentException: Cannot
format given Object as a Number
at java.text.DecimalFormat.format(DecimalFormat.java:480)
at java.text.Format.format(Format.java:133)
i tried a variation of it:
new DecimalFormat("000").format(1: long);
still the same.
another variation i tried is:
new DecimalFormat("000").format[long](1);
of course that gave me an compile time error.
overloaded method format of type
(scala.Any,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and>
(scala.Double,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and>
(scala.Long,java.lang.StringBuffer,java.text.FieldPosition)java.lang.StringBuffer
<and> (scala.Any)java.lang.String cannot be applied to (scala.Long)
any help would be greatly appriciated.
ciao robertj
Date: August 24, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<430CEC26.7070500@xxxxxxxxxxx>
References:
<430CE59A.3000006@xxxxxxxx> <430CEC26.7070500@xxxxxxxxxxx>
On Wed, Aug 24, 2005 at 10:52:38PM +0100, Jon Pretty wrote: > I suspect this option currently does nothing - see the language spec > (http://scala.epfl.ch/docu/files/ScalaReference.pdf) Chapter B, item 3 > (page 117) for a bit more information. Actually it enables the experimental RTT support. But the above reference at least lists what -Xrtt is supposed to fix. -- Jamie Webb
Date: August 24, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx> <91a2ba3e05082413584f76aca3@xxxxxxxxxxxxxx>
On Wed, Aug 24, 2005 at 01:58:43PM -0700, Raoul Duke wrote: > From what little reading I've done, the problem description is even > 'more' than that. In particular, not adding a new member but simply > changing its internal implementation, while supposedly leaving its > external behaviour alone, can break things. There are at least three definitions for 'fragile base class problem'. Martin's one, your one, and a third relating to binary interfaces in statically bound OO languages. > Supposedly, one 'easy' way to design for it is by requiring a) private > methods only call private methods, never public and b) protected > methods are mostly final, unless you carefully examine the possible > repurcussions of them being virtual. A simpler approach is just to avoid overriding unless the class documentation says it's safe. In my experience, use of overriding usually falls into one of two categories: a) Implementing methods that would've been abstract, but a convenient default was provided. And that fact is hopefully documented. Object.toString is a perfect example. b) Attempts to repurpose existing code. Aldrich's CountingSet is an example of this. Unfortunately in the early days of OOP this form of reuse was considered a major selling point and actively encouraged, but it turned out to be a bad idea in general. If you control the existing code, consider refactoring (Scala's mixins are useful here). If not, best to treat it as a black box. CountingSet should have been implemented by delegating to a Set member rather than inheriting (i.e. the Adaptor pattern). > But, it would be useful to have a way to be more explicit e.g.: the > 'open' keyword that Aldrich et. al. implement. That solves one problem (at the expense of some additional language complexity), but there are many others related to it. For example, what if Set were modified to have additional methods which add members? Best just to avoid that programming style altogether. -- Jamie Webb
Date: August 24, 2005
From: Jon Pretty <jon.pretty@xxxxxxxxxxx>
In-reply-to:
<430CE59A.3000006@xxxxxxxx>
References:
<430CE59A.3000006@xxxxxxxx>
Hi Robert, I suspect this option currently does nothing - see the language spec (http://scala.epfl.ch/docu/files/ScalaReference.pdf) Chapter B, item 3 (page 117) for a bit more information. Regards, Jon robert kuzelj wrote: >hi, > >can anybody point me to docs for the -Xrtt >option of scalac. or maybe explain what the >short info "Enable run-time types" really means. > >thanks. > >ciao robertj > > > .
Date: August 24, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi, can anybody point me to docs for the -Xrtt option of scalac. or maybe explain what the short info "Enable run-time types" really means. thanks. ciao robertj
Date: August 24, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<430C4FA8.4000106@xxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <430C4FA8.4000106@xxxxxxx>
> In a nutshell, the "fragile baseclass problem" means that adding a > member to a class might break client code that inherits from that class > and already defines that member (possibly with a different meaning). In > Java, the member in the client class would override the member in the > base class, and so lead to incorrect code. Since clients are usually > unknown, one cannot modify a base class by adding new members in a later > version without risking to break existing code. Hello Martin, >From what little reading I've done, the problem description is even 'more' than that. In particular, not adding a new member but simply changing its internal implementation, while supposedly leaving its external behaviour alone, can break things. Supposedly, one 'easy' way to design for it is by requiring a) private methods only call private methods, never public and b) protected methods are mostly final, unless you carefully examine the possible repurcussions of them being virtual. But, it would be useful to have a way to be more explicit e.g.: the 'open' keyword that Aldrich et. al. implement. sincerely.
Date: August 24, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx>
> Can you explain the philosophical difference ? hello Vincent, Yes, I am not sure that it matters much, functionval vs. oo (vs. whatever). I concurr that boiling it down, the basic idea that code can become interdependent in painful ways is sort of an obvious statement! Probably, everybody thought that somehow (?!) doing things in a OO way would get around that, because you'd mark things private and that would 'obviously' take care of things. That certainly seems like the hype around OO, that everything will be extensible, no problem! Perhaps it then comes as a surprise when it isn't so easy? sincerely.
Date: August 24, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<200508241943.j7OJhEiI020690@xxxxxxxxxxxx>
References:
<1124873529.430c35396d3e2@xxxxxxxxxxxxxxx> <200508241943.j7OJhEiI020690@xxxxxxxxxxxx>
On Wed, Aug 24, 2005 at 09:43:00PM +0200, Irina Rychkova wrote: > Hello, > > The expression: > > X.value.asInstanceOf(Map[Int,Int]) > > Where <value> is initially declared as <Any>, gives an error : Object Map > cannot be applied to (Int,Int) You want X.value.asInstanceOf[Map[Int,Int]] Note square brackets. -- Jamie Webb
Date: August 24, 2005
From: "Irina Rychkova" <irina.rychkova@xxxxxxx>
In-reply-to:
<1124873529.430c35396d3e2@xxxxxxxxxxxxxxx>
References:
<1124873529.430c35396d3e2@xxxxxxxxxxxxxxx>
Hello, The expression: X.value.asInstanceOf(Map[Int,Int]) Where <value> is initially declared as <Any>, gives an error : Object Map cannot be applied to (Int,Int) ... Thanx in advance for the solution! Irina
Date: August 24, 2005
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0508241444370.4027@xxxxxxxxxxxxx>
Raoul Duke wrote: > There's the quintissential 'fragile base class' problem which dogs the > use of inheritance. Various folks have proposed ways to work around it > (e.g.: selective open recursion from Aldrich). How are / might such > things be done in Scala?In a nutshell, the "fragile baseclass problem" means that adding a member to a class might break client code that inherits from that class and already defines that member (possibly with a different meaning). In Java, the member in the client class would override the member in the base class, and so lead to incorrect code. Since clients are usually unknown, one cannot modify a base class by adding new members in a later version without risking to break existing code.
There are schemes around this, but they tend to be difficult and costly to implement on a Java VM. In Scala, the problem is a bit alleviated: Because overriding methods need to have an `override' modifier, adding a new method to a base class that's already defined in a client will lead to a compile time error (because the client already defines that method, but without an `override' modifier). This is still not ideal, but much preferable to changing behavior at runtime, as is done in Java.
Of course, the error is only detected in Scala if the client class is actually recompiled. But this is true also of many other forms of binary incompatibility. Because Scala's type model is richer than Java's we have to rely on the compiler to catch Scala-speicifc errors. Java's bytecode verifier alone will not do that.
Cheers -- Martin
Date: August 24, 2005
From: Vincent Cremet <vincent.cremet@xxxxxxx>
In-reply-to:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx>
References:
<91a2ba3e050823172727a120df@xxxxxxxxxxxxxx>
Hi Raoul, I am happy to have the opportunity to understand the "fragile base class problem".For the moment, after the little I have read, I don't see why this problem is related to object-orientation and inheritance. In a functional world, if a function f is defined using another function g and that someone changes the implementation of g, the behaviour of f will change. In an object-oriented world, if a class A extends another class B and that someone changes the implementation of B the behaviour of instances of A will change.
Can you explain the philosophical difference ? Vincent. On Tue, 23 Aug 2005, Raoul Duke wrote:
I've been engaged in a discussion re: 'final' in Java and it led me to
wonder about this...
("fragile base class" didn't turn up any good hits in GAME or Google.)
There's the quintissential 'fragile base class' problem which dogs the
use of inheritance. Various folks have proposed ways to work around it
(e.g.: selective open recursion from Aldrich). How are / might such
things be done in Scala?
sincerely.
Date: August 24, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<0ILO00IM1W28CB@xxxxxxxxxxxxx>
References:
<0ILO00IM1W28CB@xxxxxxxxxxxxx>
Hello Irina,
initialize the variables, and wrap the "Int" in a proper class type ...
object o3 extends o1.MyModel {
case class MyInt(i:Int) extends Price with Stock;
type PriceType = MyInt;
type StockType = MyInt;
var p: MyInt = _; // is null now
var s = MyInt(23);
}
In your code, the problem was that Int is not a subtype of Price. It cannot be,
because Int is fixed for every Scala program. When one defines type members and
bounds together, it means a refinement of the model must create a new class that
inherits from the one given as bound. Above, MyInt inherits from both, Price and
Stock.
About the AnyRef:
In the Scala world, all objects are instances of either AnyVal or AnyRef.
Those who are instances of AnyVal seem to be objects, but they require little
storage space which moreover is known in advance. The subclasses of AnyVal are
called value types (Int, Boolean, Char, ... ) and they will be turn into real
objects ("boxed") whenever needed, you don't need to worry about this.
Every other type (like MyInt, String, ...) is called a reference type and
objects will be represented by pointers to some place in memory.
Only when you create an Array[A] where A is a type variable, the compiler will
complain that it does not know whether to make an Array for a value type or for
a reference type. That's where saying A <: AnyRef helps.
hope this helps,
Burak
Quoting Irina Rychkova <irina.rychkova@xxxxxxx>:
> Hello Burak!
>
> Thanx for the explanation.
>
> The lst realization you recommended seems the most reasonable for my case.
> However I got one problem with it. My version is the following:
>
> //o1.scala
> Object o1 {
>
> trait MyModel { // encapsulate stuff in trait
> trait Price;
> trait Stock;
> type PriceType <: Price;
> type StockType <: Stock;
>
> var p: PriceType;
> var s: StockType;
>
> def foo(x:PriceType): StockType;
> }
>
> }
> //o2.scala
> object o2{
>
> import o1._;
>
> object o3 extends o1.MyModel{
> type PriceType=Int;
> type StockType=Int;
>
> //1) Object cannot be created without definition of p and s...?
> //2) type PriceType = Int cannot override the type PriceType bounded in
> o1.Mymodel by Price
>
> }
>
>
> Should I bound Price by AnyRef somewhere?
> Or such an object structure is wrong?
>
> Thank you!
> Irina
>
>
> -----Original Message-----
> From: burak.emir@xxxxxxx [mailto:burak.emir@xxxxxxx]
> Sent: mardi, 23. août 2005 09:01
> To: Irina Rychkova
> Cc: scala@xxxxxxxxxxxxxx
> Subject: Re: Type renaming
>
> Hello Irina,
>
> From your description below, I assume you want type *abstraction*, not type
> renaming: the Product should "abstract over types Price and Stock", that is,
> should work for different concrete types Price and Stock.
>
> There are currently two ways to abstract over types: generics and type
> members.
> The former can be encoded in the latter.
>
> //generics
> class Product[Price, Stock] {
> var p:Price;
> var s:Stock;
> }
> ... val myprod = new Product[Int, Int];
>
> // type members
> abstract class Product {
> type Price;
> type Stock;
> var p: Price;
> var s: Stock;
> }
> class MyProduct extends Product {
> type Price = Int;
> type Stock = Int;
> }
>
> A few traps when using generics: If you want to use Array[A] for some type
> parameter A, then you should give an upper bound A <: AnyRef or A <: AnyVal.
> Similarly, if you want to have null assigned to variables of type A, you
> should give an upper bound A <: AnyRef. This looks as follows
>
> class Product[Price <: AnyRef, Stock <: AnyRef] {
> var p:Price;
> ...
> }
> abstract class Product {
> type Price <: AnyRef;
> ...
> }
>
> Note that there is no text-substitution like the template mechanism in C++.
> Meaning that whenever you make subclasses and change the types Price and
> Stock, you will have to supply "conforming" types (subclasses!).
>
> For type "Int" there are no conforming types except "Int", so type
> abstraction would not make much sense. However, you can add traits "Price"
> and "Stock" and gain much flexibility. This is the style which uses most of
> Scala's type system
>
> trait MyModel { // encapsulate stuff in trait
> trait Price;
> trait Stock;
> type PriceType <: Price;
> type StockType <: Stock;
>
> var p: PriceType;
> var s: StockType;
>
> def foo(x:PriceType): StockType;
> }
>
> trait MyRefinedModel extends MyModel {
> case class RefinedPrice(p:Int) extends super.Price { ... }
> case class RefinedStock(p:Int) extends super.Stock { ... }
> type PriceType <: RefinedPrice;
> type StockType <: RefinedStock;
>
> def foo(x:PriceType): StockType = {...}; }
>
> object UseRefinedModel extends MyRefinedModel {
> type PriceType = RefinedPrice; // tie the knot
> type StockTYpe = RefinedStock;
>
> def main() {
> val x: RefinedPrice = ...;
> RefinedStock rs = foo(x);
> }
> }
>
> hope this helps,
> Burak
>
>
>
Date: August 24, 2005
From: Raoul Duke <raould@xxxxxxxxx>
I've been engaged in a discussion re: 'final' in Java and it led me to
wonder about this...
("fragile base class" didn't turn up any good hits in GAME or Google.)
There's the quintissential 'fragile base class' problem which dogs the
use of inheritance. Various folks have proposed ways to work around it
(e.g.: selective open recursion from Aldrich). How are / might such
things be done in Scala?
sincerely.
Date: August 23, 2005
From: "Irina Rychkova" <irina.rychkova@xxxxxxx>
In-reply-to:
<1124780462.430ac9ae2bd89@xxxxxxxxxxxxxxx>
References:
<1124780462.430ac9ae2bd89@xxxxxxxxxxxxxxx>
Hello Burak!
Thanx for the explanation.
The lst realization you recommended seems the most reasonable for my case.
However I got one problem with it. My version is the following:
//o1.scala
Object o1 {
trait MyModel { // encapsulate stuff in trait
trait Price;
trait Stock;
type PriceType <: Price;
type StockType <: Stock;
var p: PriceType;
var s: StockType;
def foo(x:PriceType): StockType;
}
}
//o2.scala
object o2{
import o1._;
object o3 extends o1.MyModel{
type PriceType=Int;
type StockType=Int;
//1) Object cannot be created without definition of p and s...?
//2) type PriceType = Int cannot override the type PriceType bounded in
o1.Mymodel by Price
}
Should I bound Price by AnyRef somewhere?
Or such an object structure is wrong?
Thank you!
Irina
-----Original Message-----
From: burak.emir@xxxxxxx [mailto:burak.emir@xxxxxxx]
Sent: mardi, 23. août 2005 09:01
To: Irina Rychkova
Cc: scala@xxxxxxxxxxxxxx
Subject: Re: Type renaming
Hello Irina,
>From your description below, I assume you want type *abstraction*, not type
renaming: the Product should "abstract over types Price and Stock", that is,
should work for different concrete types Price and Stock.
There are currently two ways to abstract over types: generics and type
members.
The former can be encoded in the latter.
//generics
class Product[Price, Stock] {
var p:Price;
var s:Stock;
}
... val myprod = new Product[Int, Int];
// type members
abstract class Product {
type Price;
type Stock;
var p: Price;
var s: Stock;
}
class MyProduct extends Product {
type Price = Int;
type Stock = Int;
}
A few traps when using generics: If you want to use Array[A] for some type
parameter A, then you should give an upper bound A <: AnyRef or A <: AnyVal.
Similarly, if you want to have null assigned to variables of type A, you
should give an upper bound A <: AnyRef. This looks as follows
class Product[Price <: AnyRef, Stock <: AnyRef] {
var p:Price;
...
}
abstract class Product {
type Price <: AnyRef;
...
}
Note that there is no text-substitution like the template mechanism in C++.
Meaning that whenever you make subclasses and change the types Price and
Stock, you will have to supply "conforming" types (subclasses!).
For type "Int" there are no conforming types except "Int", so type
abstraction would not make much sense. However, you can add traits "Price"
and "Stock" and gain much flexibility. This is the style which uses most of
Scala's type system
trait MyModel { // encapsulate stuff in trait
trait Price;
trait Stock;
type PriceType <: Price;
type StockType <: Stock;
var p: PriceType;
var s: StockType;
def foo(x:PriceType): StockType;
}
trait MyRefinedModel extends MyModel {
case class RefinedPrice(p:Int) extends super.Price { ... }
case class RefinedStock(p:Int) extends super.Stock { ... }
type PriceType <: RefinedPrice;
type StockType <: RefinedStock;
def foo(x:PriceType): StockType = {...}; }
object UseRefinedModel extends MyRefinedModel {
type PriceType = RefinedPrice; // tie the knot
type StockTYpe = RefinedStock;
def main() {
val x: RefinedPrice = ...;
RefinedStock rs = foo(x);
}
}
hope this helps,
Burak
Date: August 23, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<d51e7cf85d920cb15516de82e5470d8d@xxxxxxxxxx>
References:
<43085D73.9080403@xxxxxxxx> <dec63q$lqo$1@xxxxxxxxxxxxx> <d51e7cf85d920cb15516de82e5470d8d@xxxxxxxxxx>
hi matthias,
> As far as I can see, this is not a bug. Scala has
> the notion of "overloaded definitions". According
> to §4.6 of the language spec, such a definition consists
> of the set of all value/function definitions that bind
> the same name to different types (called alternatives).
> If you want to override such an overloaded definition,
> you have to override all alternatives at the same time
> according to §5.1.5 and §3.5.2. So, in the code below,
> bar in FooImpl is actually not overriding anything.
> As far as I can see, the reason why overriding is unclear
> relates to the definition of "subsumption" in §3.5.2
> which does not talk about methods.
i am not going to argue about the spec. probably it says
what you say it says. nevertheless the question remains
if the spec does a sensible thing.
regardless that i personally dont agree with the spec
the compiler seems to have a problem with it too.
this code:
trait Foo
{
def bar(x: String): Foo = null;
def bar(x: String, y: String): Foo = null;
def bar(x: String, y: String, z: String): Foo = null;
}
class FooImpl with Foo
{
def bar(x: String, y: String, z: String): Foo = null;
}
var foo = new FooImpl;
foo.bar("x", "y", "z");
yields this compiler error
method bar in class FooImpl needs `override' modifier
def bar(x: String, y: String, z: String): Foo = null;
which is ok if you ask me. so i change it to
override def bar(x: String, y: String, z: String): Foo = null;
which compiles ok then. but according to the spec this shouldnt
be possible. because i would have to override all of the
overloaded methods.
so anyway it is a bug if you ask me. either the spec should be
changed to allow for overriding overloaded methods or the
compiler may not allow that. or i may define a new method
(not override it) with the same signature in a child class.
ciao robertj
Date: August 23, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<0ILM0075AWBWBL@xxxxxxxxxxxxx>
References:
<0ILM0075AWBWBL@xxxxxxxxxxxxx>
Hello Irina,
>From your description below, I assume you want type *abstraction*, not type
renaming: the Product should "abstract over types Price and Stock", that is,
should work for different concrete types Price and Stock.
There are currently two ways to abstract over types: generics and type members.
The former can be encoded in the latter.
//generics
class Product[Price, Stock] {
var p:Price;
var s:Stock;
}
... val myprod = new Product[Int, Int];
// type members
abstract class Product {
type Price;
type Stock;
var p: Price;
var s: Stock;
}
class MyProduct extends Product {
type Price = Int;
type Stock = Int;
}
A few traps when using generics: If you want to use Array[A] for some type
parameter A, then you should give an upper bound A <: AnyRef or A <: AnyVal.
Similarly, if you want to have null assigned to variables of type A, you should
give an upper bound A <: AnyRef. This looks as follows
class Product[Price <: AnyRef, Stock <: AnyRef] {
var p:Price;
...
}
abstract class Product {
type Price <: AnyRef;
...
}
Note that there is no text-substitution like the template mechanism in C++.
Meaning that whenever you make subclasses and change the types Price and Stock,
you will have to supply "conforming" types (subclasses!).
For type "Int" there are no conforming types except "Int", so type abstraction
would not make much sense. However, you can add traits "Price" and "Stock" and
gain much flexibility. This is the style which uses most of Scala's type system
trait MyModel { // encapsulate stuff in trait
trait Price;
trait Stock;
type PriceType <: Price;
type StockType <: Stock;
var p: PriceType;
var s: StockType;
def foo(x:PriceType): StockType;
}
trait MyRefinedModel extends MyModel {
case class RefinedPrice(p:Int) extends super.Price { ... }
case class RefinedStock(p:Int) extends super.Stock { ... }
type PriceType <: RefinedPrice;
type StockType <: RefinedStock;
def foo(x:PriceType): StockType = {...};
}
object UseRefinedModel extends MyRefinedModel {
type PriceType = RefinedPrice; // tie the knot
type StockTYpe = RefinedStock;
def main() {
val x: RefinedPrice = ...;
RefinedStock rs = foo(x);
}
}
hope this helps,
Burak
Quoting Irina Rychkova <irina.rychkova@xxxxxxx>:
>
> Hello!
>
> I'm using scala for the theory formalisation and need to have the explicit
> type specification in my scala program, for instance,
> Is it possible to rename the standard Int? like:
>
> trait Price = Int;
> trait Stock = Int;
> ...
> Class Product {
> var p:Price;
> var s:Stock;
>
> }
>
> The idea is to be able to change the Price and Stock definitions on the
> following modeling levels but to use the same Product definition.
>
> Thank you.
> Irina Rychkova
>
>
Date: August 23, 2005
From: Matthias Zenger <mail@xxxxxxxxxx>
In-reply-to:
<dec63q$lqo$1@xxxxxxxxxxxxx>
References:
<43085D73.9080403@xxxxxxxx> <dec63q$lqo$1@xxxxxxxxxxxxx>
Actually, you don't need to log in the bug tracking system to add or look at bugs (only modifying them requires an account). You can add your own bugs on http://lamppc1s1.epfl.ch/bugtracking/contribs/load.doI would recommend you add your bug report (it does look like a bug, indeed) to the bug-tracking system. Otherwise it will hopelessly get lost in the masses of messages of the newsgroup, I fear.
As far as I can see, this is not a bug. Scala has the notion of "overloaded definitions". According to §4.6 of the language spec, such a definition consists of the set of all value/function definitions that bind the same name to different types (called alternatives). If you want to override such an overloaded definition, you have to override all alternatives at the same time according to §5.1.5 and §3.5.2. So, in the code below, bar in FooImpl is actually not overriding anything. As far as I can see, the reason why overriding is unclear relates to the definition of "subsumption" in §3.5.2 which does not talk about methods. == Matthias
given the folliwng code trait Foo { def bar(x: String): Foo = null; def bar(x: String, y: String): Foo = null; def bar(x: String, y: String, z: String): Foo = null; } class FooImpl with Foo { override def bar(x: String, y: String, z: String): Foo = null; } object FooApp { def main(args: Array[String]):Unit = { var foo = new FooImpl; foo.bar("x"); } } i get this compiler error: overloaded method bar of type(java.lang.String,java.lang.String,java.lang.String)org.pragmatico.scu nit.Foo<and> (java.lang.String,java.lang.String)org.pragmatico.scunit.Foocannot be applied to (java.lang.String) with expected result type scala.Unitfoo.bar("x"); if i remove the overriden method from FooImpl the error vanishes. if i add another method FooImpl#override def bar(x: String): Foo = null; all is ok too.
Date: August 22, 2005
From: "Irina Rychkova" <irina.rychkova@xxxxxxx>
In-reply-to:
<4309E172.9020302@xxxxxxxxxxx>
References:
<4309E172.9020302@xxxxxxxxxxx>
Hello!
I'm using scala for the theory formalisation and need to have the explicit
type specification in my scala program, for instance,
Is it possible to rename the standard Int? like:
trait Price = Int;
trait Stock = Int;
...
Class Product {
var p:Price;
var s:Stock;
}
The idea is to be able to change the Price and Stock definitions on the
following modeling levels but to use the same Product definition.
Thank you.
Irina Rychkova
Date: August 22, 2005
From: Jon Pretty <jon.pretty@xxxxxxxxxxx>
In-reply-to:
<4309DEFB.9030600@xxxxxxxx>
References:
<4309DEFB.9030600@xxxxxxxx>
Hi Robert,
You want to change your definition of foo to:
def foo(x : String*) = bar(x : _*);
which will call bar with the parameter x in the form of varargs, rather
than as a single parameter of type Seq[String].
Regards,
Jon
robert kuzelj wrote:
>hi,
>
>not sure if this is a bug (at least it is very unexpected)
>
> def foo(x: String*) = bar(x);
> def bar(y: String*) = Console.println(y);
>
> foo("eins", "zwei", "drei");
>
>this gives me
>
>type mismatch;
> found : scala.Seq[java.lang.String]
> required: java.lang.String
> def foo(x: String*) = bar(x);
>
>the workaround is to change bar as follows
>
>def bar(y: Seq[String]) = Console.println(y);
>
>sadly it is not possible to overload bar. as
>
>def bar(y: Seq[String]) = Console.println(y);
>def bar(y: String*) = Console.println(y);
>
>are the same after type erasure.
>
>ciao robertj
>
>
>
Date: August 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi,
not sure if this is a bug (at least it is very unexpected)
def foo(x: String*) = bar(x);
def bar(y: String*) = Console.println(y);
foo("eins", "zwei", "drei");
this gives me
type mismatch;
found : scala.Seq[java.lang.String]
required: java.lang.String
def foo(x: String*) = bar(x);
the workaround is to change bar as follows
def bar(y: Seq[String]) = Console.println(y);
sadly it is not possible to overload bar. as
def bar(y: Seq[String]) = Console.println(y);
def bar(y: String*) = Console.println(y);
are the same after type erasure.
ciao robertj
Date: August 22, 2005
From: Gilles Dubochet <dubochet@xxxxxxxxxx>
References:
<43085D73.9080403@xxxxxxxx>
Hello,
since i cant login into the bug reporting system i post it here. hope thats ok.
Actually, you don't need to log in the bug tracking system to add or look at bugs (only modifying them requires an account). You can add your own bugs on http://lamppc1s1.epfl.ch/bugtracking/contribs/load.do
I would recommend you add your bug report (it does look like a bug, indeed) to the bug-tracking system. Otherwise it will hopelessly get lost in the masses of messages of the newsgroup, I fear.
Have fun developing with Scala, Sincerely, Gilles Dubochet.
given the folliwng code
trait Foo
{
def bar(x: String): Foo = null;
def bar(x: String, y: String): Foo = null;
def bar(x: String, y: String, z: String): Foo = null;
}
class FooImpl with Foo
{
override def bar(x: String, y: String, z: String): Foo = null;
}
object FooApp
{
def main(args: Array[String]):Unit =
{
var foo = new FooImpl;
foo.bar("x");
}
}
i get this compiler error:
overloaded method bar of type
(java.lang.String,java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
<and> (java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
cannot be applied to (java.lang.String) with expected result type scala.Unit
foo.bar("x");
if i remove the overriden method from FooImpl the error vanishes.
if i add another method
FooImpl#override def bar(x: String): Foo = null;
all is ok too.
Date: August 21, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<430904E7.2030504@xxxxxxxxxxx>
References:
<43085D73.9080403@xxxxxxxx> <430904E7.2030504@xxxxxxxxxxx>
hi, > as far as I understood it hat nothing to to w/ traits, since it also > fails for abstract classes. it happens whenever you override not all >polymorphic methods from a superclass. the interessting part on it is that a few methods seem to be available even thou those are not overridden. > I'm too new new to Scala in order to be allowed to say that it's a bug, > but at least it is not helpful. :-) ciao robertj
Date: August 21, 2005
From: Frank Bechmann <fBechmann@xxxxxxxxxxx>
In-reply-to:
<43085D73.9080403@xxxxxxxx>
References:
<43085D73.9080403@xxxxxxxx>
robert kuzelj wrote:
hi,
since i cant login into the bug reporting system i post
it here. hope thats ok.
given the folliwng code
trait Foo
{
def bar(x: String): Foo = null;
def bar(x: String, y: String): Foo = null;
def bar(x: String, y: String, z: String): Foo = null;
}
class FooImpl with Foo
{
override def bar(x: String, y: String, z: String): Foo = null;
}
object FooApp
{
def main(args: Array[String]):Unit =
{
var foo = new FooImpl;
foo.bar("x");
}
}
i get this compiler error:
overloaded method bar of type
(java.lang.String,java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
<and> (java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
cannot be applied to (java.lang.String) with expected result type scala.Unit
foo.bar("x");
if i remove the overriden method from FooImpl the error vanishes.
if i add another method
FooImpl#override def bar(x: String): Foo = null;
all is ok too.
ciao robertj
Date: August 21, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi,
since i cant login into the bug reporting system i post
it here. hope thats ok.
given the folliwng code
trait Foo
{
def bar(x: String): Foo = null;
def bar(x: String, y: String): Foo = null;
def bar(x: String, y: String, z: String): Foo = null;
}
class FooImpl with Foo
{
override def bar(x: String, y: String, z: String): Foo = null;
}
object FooApp
{
def main(args: Array[String]):Unit =
{
var foo = new FooImpl;
foo.bar("x");
}
}
i get this compiler error:
overloaded method bar of type
(java.lang.String,java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
<and> (java.lang.String,java.lang.String)org.pragmatico.scunit.Foo
cannot be applied to (java.lang.String) with expected result type scala.Unit
foo.bar("x");
if i remove the overriden method from FooImpl the error vanishes.
if i add another method
FooImpl#override def bar(x: String): Foo = null;
all is ok too.
ciao robertj
Date: August 18, 2005
From: Martin Schaffner <schaffner@xxxxxx>
In-reply-to:
<43035F39.6060804@xxxxxxxx>
References:
<43035A61.8060404@xxxxxxxx> <43035F39.6060804@xxxxxxxx>
robert kuzelj wrote:
hi,
this is probably one of the dumbest questions ever...
but how the $%!§ do i append an item at the end of a list
so that i get a list like this -> List(1,2,3,4)
this is what i tried.
var x = List(1,2,3);
//var z = 4 :: x;
this works, but does not return the desired result
//var z = x.append(4);
//var z = x.add(4);
//var z = x ::: 4;
//var z = x << 4;
//var z = x <<< 4;
//var z = x + 4;
//var z = x >> 4;
//var z = x ::: List(4);
this last one does what you want. If it did not seem to work for you, maybe you ran into a bug like this one?
http://lamppc1s1.epfl.ch/bugtracking/contribs/display.do?id=69
Date: August 17, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050817213926.GO15684@xxxxxxxxxxxxxxxx>
References:
<43039D7F.6020103@xxxxxxxx> <20050817213926.GO15684@xxxxxxxxxxxxxxxx>
> I don't believe it's possible in any nice fashion. I gave up and went
> for the 'cuddled' style.
i found a way by using an infix operator ::.
it looks something like this then:
b op1 {} ::
op2 {} ::
op3 {};
thou i have a bug still there. i post the complete solution
when i have a working solution.
>The only alternative I can think of is to use
> the method call syntax:
>
> b.op1 {}
> .op2 {}
> .op3 {};
that is absolutely fine for me.
thanks.
ciao robertj
Date: August 17, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050817212842.GN15684@xxxxxxxxxxxxxxxx>
References:
<43035A61.8060404@xxxxxxxx> <43035F39.6060804@xxxxxxxx> <20050817212842.GN15684@xxxxxxxxxxxxxxxx>
hi jamie, > List is an immutable singly-linked list. Use it if you want to program > in a functional style. ah, i guess this is the most important thing on it. >If you're not familiar with functional > programming, I highly recommend reading up on either Scheme or ML; > understanding functional programming style will make you a better > all-round programmer. <sigh> so many things to learn. if days only had 48 hours. anyways thanks for the suggestion. functional programming is certainly a thing missing from my toolset. ciao robertj