Adding ??? to Predef?

[martin odersky]

If people don't hold me back I will commit the following addition to Predef.

/** Throws an UnsupportedOperationException.
* Convenient as a placeholder for a missing right-hand-side of a method.
*/
def ??? : Nothing = throw new UnsupportedOperationException("not implemented")

I have been defining this method myself in more and more projects
because I find it both cute and convenient to use

def foo(x: String): String = ???

for a not-yet implemented method. Also makes for a great teaching
tool. Just tell you class to replace the ???'s.

What do you think?

Cheers

-- Martin

[Louis Botterill]

Brilliant, I'd love it personally. So often I want to get some outline structure to compile then come back and fill in some details - nice idea, I'd use it immediately!

[David Hall]

+1. FWIW, I've been using TODO, which might be a little more transparent...

-- David

[Simon Ochsenreither]

I like it too. Just wondering if it is the most general solution or if there might be related functionality which can be folded into it ...

[Jon-Anders Teigen]

I would prefer you didn't commit this for a couple of reasons.

* I am not sure ??? is so much better than for example a method called "notImplemented", "TODO" or something else that it warrants the introduction of a new symbolic method globally available in all scala programs.
* I dislike encouraging the use of UnsupportedOperationException. Like casting (asInstanceOf[T] vs (T) from java) it really shouldn't be used much and its ok that it screams at you and is somewhat clumsy to type.
* If one really wants this and like using UnsupportedOperations its as simple as adding it to your own package object with the added benefit that you can remove it too when you don't want it anymore.

I wouldn't mind having it available in a trait, ready to be mixed into my own package object for example in the context of teaching, but I really don't want a ??? lurking among the !!, !? and ?s and all the other symbols in my production code.

/j

[Ismael Juma]

I like TODO better myself. Apart from being more readable, most IDEs have support for showing all TODOs in a codebase.

[Chris Twiner]

+1

[Kevin Wright]

+1 for naming it TODO

If I wanted a glut of extra symbols in my code, we have libraries which can do that :)

[Paul Phillips]

I also prefer TODO.

[martin odersky]

On Sat, Oct 1, 2011 at 2:25 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> +1 for naming it TODO
> If I wanted a glut of extra symbols in my code, we have libraries which can
> do that :)

I agree that we should generally try to set a good example wrt
symbolic operators. TODO would be fine for me as well. But I find ???
works visually better for me, and I believe it's pretty easy to guess
what ??? could be, unlike some of the other symblic operators that we
come across.

I'd be interested in people trying out both variants in their code and
then reporting which works better for them. I find ??? easier on the
eye than TODO
and also easier to indicate that something is missing. TODO looks too
much like a constant for me.

Cheers

-- Martin

Cheers

-- Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Paul Phillips]

On Sat, Oct 1, 2011 at 5:52 AM, martin odersky <martin....@epfl.ch> wrote:
> TODO looks too much like a constant for me.

Does tend to match up with reality though.

[Josh Suereth]

I'm still in favor of TODO or `undefined`.  ??? is just asking for anti-operator-overloading-ite criticism.

In a similar vein, I have a project that allows me to write  `O NOES !!` for these types of methods, which, although more characters, is much more fun to write.

[martin odersky]

True...

[martin odersky]

On Sat, Oct 1, 2011 at 3:04 PM, Josh Suereth <joshua....@gmail.com> wrote:
> I'm still in favor of TODO or `undefined`.  ??? is just asking for

> anti-operator-overloading-ite criticism.out ToDo

What about ToDo? I guess I just don't like the all-caps style of TODO.

-- Martin

[Paul Phillips]

I like ToDo better.

Another possibility is ToodleOo, since you're throwing an exception
you may as well say goodbye.

[Daniel Sobral]

On Sat, Oct 1, 2011 at 09:52, martin odersky <martin....@epfl.ch> wrote:
> On Sat, Oct 1, 2011 at 2:25 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
>> +1 for naming it TODO
>> If I wanted a glut of extra symbols in my code, we have libraries which can
>> do that :)
>
> I agree that we should generally try to set a good example wrt
> symbolic operators. TODO would be fine for me as well. But I find ???
> works visually better for me, and I believe it's pretty easy to guess
> what ??? could be, unlike some of the other symblic operators that we
> come across.
>
> I'd be interested in people trying out both variants in their code and
> then reporting which works better for them. I find ??? easier on the
> eye than TODO
> and also easier to indicate that something is missing. TODO looks too
> much like a constant for me.

I find ??? works better visually -- alphanumeric identifiers just
look like business as usual. Syntax highlighting could compensate for
that, but demanding increased support kind of goes against the very
spirit of the brevity of ??? or TODO.

I don't like ToDo. While TODO looks like a Java constant, ToDo looks
like a *Scala* constant or class. TODO stands out much better than
ToDo. Besides, it looks better on slides.

I'm not sure about adding it to predef, particularly "???", for which
I'd check Scalaz, Unfiltered, Dispatcher, Akka and Specs before
trusting it was not used.

Finally, if this gets added at all, there *must* be a compiler switch
that would turn it into a compiler error. Sure, unit tests ought to
catch them all, but that presumes all unit tests were written in first
place. I don't care much for a compiler switch that changes the
meaning of a simple, valid, Scala definition, but given the incentive
this would cause, having some tool to cope with the downsides would be
very desirable.

--
Daniel C. Sobral

I travel to the future all the time.

[Ismael Juma]

On 1 Oct 2011 14:23, "Paul Phillips" <pa...@improving.org> wrote:
>
> I like ToDo better.

Me too.

Best,
Ismael

[Lieven Lemiengre]

I don't like 'ToDo', I frequently use todo as a variable name it would be confusing, '???' would be better or 'NotImplemented'

Lieven.

[Doug Tangren]

On Sat, Oct 1, 2011 at 12:39 PM, Lieven Lemiengre <lieven.l...@gmail.com> wrote:

I don't like 'ToDo', I frequently use todo as a variable name it would be confusing, '???' would be better or 'NotImplemented'

with _ already being used as a "place holder" for values and for denoting a point for completion in curried functions in scala, why not build the idea of placeholder with 

def foo(x: String): String = _?  // denotes an unknown placeholder

or

de foo(x: String): String = _! // denotes an explosive placeholder (throws an exception!)

[Jon Steelman]

I prefer ??? over TODO/ToDo.

Might be nice if ??? optionally permitted a comment parameter to add detail about what needs to be done or how it can be done. The comment parameter could be used by the compiler switch that Daniel suggested and perhaps other ways.

Thanks,

Jon

[Kevin Wright]

I'd say that TODO, or NOTIMPL, or equivalent - in all caps - works precisely *because* it's so jarring.

The justification for ??? is that it stands out visually.  Using ALL CAPS achieves the same goal, especially given that Scala doesn't already use this convention for constants.


It gets even better with an optional string argument:

    def foo(x: String): String = TODO("should return a foo'd "+x)

[Erik Engbrecht]

If this is implemented, could it be accompanied by a compiler warning for all the ??? or TODO or whatever methods?

[√iktor Ҡlang]

Why not an @Todo annotation that forbids method implementation until removed, issues a compile-time warning and adds a throw as the method body?

[Archontophoenix Quar]

I habitually use TODO, but ??? does look more visually distinctive.
Maybe it's time to switch.

In the same vein:

def `!!!`: Nothing = throw new AssertionError("Can't get here")

Easier to spot than "_!"?

A

[Simon Ochsenreither]

I would suggest ??? with an optional message.

While ‘ToDo’ and others could work too, the fact that almost everybody out there took ??? instead of those speaks for itself.

[Daniel Sobral]

On Sat, Oct 1, 2011 at 15:30, Archontophoenix Quar <archo...@gmail.com> wrote:
> I habitually use TODO, but ??? does look more visually distinctive.
> Maybe it's time to switch.
>
> In the same vein:
>
>   def `!!!`: Nothing = throw new AssertionError("Can't get here")

That one *is* part of Akka, though deprecated.

[Grzegorz Kossakowski]

On 1 October 2011 10:13, martin odersky <martin....@epfl.ch> wrote:

If people don't hold me back I will commit the following addition to Predef.

 /** Throws an UnsupportedOperationException.
  *  Convenient as a placeholder for a missing right-hand-side of a method.
  */
 def ??? : Nothing = throw new UnsupportedOperationException("not implemented")

I have been defining this method myself in more and more projects
because I find it both cute and convenient to use

 def foo(x: String): String = ???

for a not-yet implemented method. Also makes for a great teaching
tool. Just tell you class to replace the ???'s.

What do you think?

+1

Regarding all other proposals. Download slides for Martin's talk: http://assets.en.oreilly.com/1/event/61/Future-proofing%20Collections_%20From%20Mutable%20to%20Persistent%20to%20Parallel%20Presentation.pdf

Scroll to "Outline of Class Coder". You'll see ?? being used there. Replace it by any other proposed name and you see that it looks much worse.

--
Grzegorz Kossakowski

[Louis Botterill]

Like the general idea, as to the exact name I've not a strong opinion, but one thing is that for example I might reserve "Todo" within general comments (in the middle of implemented functions etc) that require more work and it would be nice to be able to search for something unique in the code that won't also find all other general todos in the code as well. I suppose there could be both symbolic and descriptive alternatives, what's quite nice about ??? is that it's visually eye catching too (and fairly self-evident as to meaning?). Be nice to locate all unimplemented functions alone by searching from something with few or zero false positives.

[Ittay Dror]

What is wrong with 'error("todo")'? (I don't think the fact it throws a RuntimeException and not UnsupportedOperationException matters here)

But if something is to be added, I prefer viktorklang's @Todo suggestion.

On Saturday, October 1, 2011 11:13:42 AM UTC+3, martin odersky wrote:

If people don't hold me back I will commit the following addition to Predef.

  /** Throws an UnsupportedOperationException.
   *  Convenient as a placeholder for a missing right-hand-side of a method.
   */
  def ??? : Nothing = throw new UnsupportedOperationException("not implemented")

I have been defining this method myself in more and more projects
because I find it both cute and convenient to use

  def foo(x: String): String = ???

for a not-yet implemented method. Also makes for a great teaching
tool. Just tell you class to replace the ???'s.

What do you think?

Cheers

 -- Martin

[Jeff Olson]

Short response: Yes please!! I much prefer ??? but anything would be better than nothing.

Longer response: For what it's worth, Haskell defines such a method (called 'undefined') in it's prelude, and it's endlessly useful. I tried using 'undefined' for awhile in my scala code but it didn't look quite right. I then tried both TODO and UNDEFINED, but I found the all caps too jarring (especially when I was stubbing out a class and all methods but one or two where "UNDEFINED"). I saw Martin use ??? back at Scala Days and I thought that it was brilliant. I have been using it ever since, and I love it. My exact implementation differs a little bit:

  class UndefinedError(msg: String) extends Error(msg)
  def undefined(msg: String) = throw new UndefinedError(msg)
  def ??? = undefined("undefined")

I preferred defining a new exception class rather than use UnsupportedOperationException because I didn't want to insinuate that the method was permanently unsupported, only that it hadn't been defined yet. Finally, if I wanted to attach an error message I found
  def foo = undefined("foo is still undefined!")
to be more readable than
  def foo = ???("foo is still undefined!")

But I also understand that adding three new symbols to the Predef instead of one, is much more controversial.

-Jeff

[wookietreiber]

Personally, I find the idea of `???` intriguing, even more than `TODO`.
It's true, that IDEs highlight TODOs, but as far as I know, some of them
only within comments. `???` just stands out more, is intuitive and will
propably be not used by any other library. `ToDo` on the other hand does
not stand out that much and looks more like an ordinary method or object.

The question is, how do you choose? Do you want to dictate, as the main
scala developers, with propably the best knowledge about the language or
do you want to let the people choose, i.e. vote?

I would prefer a vote based on liquid democracy [1], not just for this one,
but for other decisions about the language, too. Let the people decide and,
if they are unsure, delegate the vote to someone else. Gathering ideas here
is a very good thing as a base for pros and cons for each possibility of a
vote.

[1] http://en.wikipedia.org/wiki/Liquid_democracy#Delegated_voting

--

best regards
Christian Krause aka wookietreiber

[Kevin Wright]

And it's not just IDE's.  CI systems, sbt and maven plugins that generate reports at build time, me using grep on the command line, etc. etc.  I quite like the idea of being able to search for both this form of TODO and TODO in comments in a single pass

There's a lot to be said for working with a convention that's already widely used and supported.

[Christos KK Loverdos]

I definitely vote for the addition of something like that in Predef.

In the past, I have personally tried and not settled among these:

- ??? (coincidentally with 3 question marks)
- NotImplementedYet
- NIY_! (the ! is to bring attention)

with an optional string parameter that contributes to the exception message.

My 2c

Christos

On Oct 1, 2011, at 11:13, martin odersky wrote:

> If people don't hold me back I will commit the following addition to Predef.
>
> /** Throws an UnsupportedOperationException.
> * Convenient as a placeholder for a missing right-hand-side of a method.
> */
> def ??? : Nothing = throw new UnsupportedOperationException("not implemented")
>
> I have been defining this method myself in more and more projects
> because I find it both cute and convenient to use
>
> def foo(x: String): String = ???
>
> for a not-yet implemented method. Also makes for a great teaching
> tool. Just tell you class to replace the ???'s.
>
> What do you think?
>
> Cheers
>
> -- Martin

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

[Peter C. Chapin]

Personally I’d prefer ??? over TODO or ToDo for this functionality. For one thing I use TODO in comments in a different way. Often I use them to remind myself about obscure bugs that I notice while developing code. For example “TODO: This won’t work on the last day of a leap year.” Here I’m too lazy (or too rushed) to deal with the issue right away but I don’t want to forget about it. It’s a different sort of thing than laying down a placeholder to get an otherwise unimplemented method to compile. Also I like the look of things like

 

val someResult = if (someCondition) doSomething() else ???

 

Regarding IDE support, I know that NetBeans can be configured to look for whatever character sequence you want when constructing it’s task list. It seems like it should be a simple matter to just add “???” to the list. I suppose other IDEs are similar, yes?

 

Peter

[wookietreiber]

iirc eclipse has configurable, priority-based highlighting for commented stuff,
TODO is normal priority, FIXME is high priority and CHANGE or so was low
priority. but thats just eclipse ...

--

best regards
Christian Krause aka wookietreiber

---------------------------------------------

heute schon gelacht? http://www.totaberlustig.com/comics/2011-09-15-Taxi.jpg

[Peter C. Chapin]

I just noticed that jEdit's TaskList plug-in searches for ??? out of the box (along with TODO, FIXME, and various others).

Peter

> -----Original Message-----
> From: scala-i...@googlegroups.com [mailto:scala-
> inte...@googlegroups.com] On Behalf Of wookietreiber
> Sent: Sunday, October 02, 2011 08:56
> To: scala-i...@googlegroups.com
> Subject: Re: [scala-internals] Re: Adding ??? to Predef?
>

[Chris Marshall]

No-one seems to have pointed out that ??? (or TODO, or whatever we call it) is *not* the same as what a thrown UnsupportedOperationException signifies. An unsupported operation is what it says on the tin, an operation which is not supported. For example, a Collections.unmodifiableList returns a List which throws a UOE when you try and mutate it. This does not mean that this functionality is not yet implemented. I would personally prefer a bespoke (runtime) exception type NotYetImplementedException, so there is zero ambiguity.

Furthermore, the implementation makes no distinction between those as-yet-unimplemented features which should cause a program to fail, and those which should not. For example, I have implemented both todo and ??? as follows:

    def ??? = throw new NotYetImplementedException

    def todo(msg: String = "", throwsException: Boolean = true) = if (throwsException) throw new NotYetImplementedException(msg)

This then gets used as follows:

    todo(msg = "should really update state at this point", throwsException = false)

Chris

[Alex Cozzi]

I really like ??? instead of TODO or anything else. It is very "scala-ish" and intuitive at the same time. While I can see the arguments for TODO being consistent with pre-existing approaches I repeatedly loved Scala for being a bit different and feeling a lot better after you get used to it. And I am not too worried about the specific implementation, since this is really supposed to be just a placeholder it needs to be visually salient and easy to type. I found ??? a great way to stub things out.
So +1 from me.
Alex

[martin odersky]

On Sun, Oct 2, 2011 at 6:24 PM, Chris Marshall <oxbow...@hotmail.com> wrote:
> No-one seems to have pointed out that ??? (or TODO, or whatever we call it)
> is *not* the same as what a thrown UnsupportedOperationException signifies.
> An unsupported operation is what it says on the tin, an operation which is
> not supported. For example, a Collections.unmodifiableList returns a List
> which throws a UOE when you try and mutate it. This does not mean that this
> functionality is not yet implemented. I would personally prefer a bespoke
> (runtime) exception type NotYetImplementedException, so there is zero
> ambiguity.
> Furthermore, the implementation makes no distinction between those
> as-yet-unimplemented features which should cause a program to fail, and
> those which should not. For example, I have implemented both todo and ??? as
> follows:
>     def ??? = throw new NotYetImplementedException
>     def todo(msg: String = "", throwsException: Boolean = true) = if
> (throwsException) throw new NotYetImplementedException(msg)
> This then gets used as follows:
>     todo(msg = "should really update state at this point", throwsException =
> false)
> Chris
>

I agree that using UnsupportedOperationException is misleading. Let's use
NotYetImplementedException.

Cheers

-- Martin

[Kevin Wright]

Perhaps we can do the same with the package as well.  Instead of using `predef`, I'd have no problem with

import literate.???

or

import scala.literate.TODO

Or any other package name that makes sense.  I like "literate" because it gives a bit of wiggle-room for adding other similar features.

The risk of name clashes from anything in predef is always high.  I'm fairly sure Paul already ran into that problem in the past; trying to implement "7 times { someBodyStuff }" to avoid the boxing penalty when using ranges, and clashed with one of the test frameworks.

[Jeff Olson]

If we are going to use a new Exception type I still prefer UndefinedException or UndefinedOperationException as I mentioned above. Both roll off the tongue a little easier than NotYetImplementedException. -Jeff

[Jon Steelman]

Perhaps you would like UnimplementedException over NotYetImplementedException?

Jon

[Dave]

I vote for:

def ??? : Nothing = throw new NotYetImplementedException

[Sébastien Doeraene]

This feature would be SO great! Especially for teaching purposes.

For that reason, I largely prefer ??? over TODO or anything else. In particular, the @Todo is just not adapted to teaching. ??? seams to be the most natural way of expressing the idea, and is so easy to write. Besides, it looks better on slides, as was already mentioned.

For the same reason, I like it being in Predef, so that we don't need to have a special import for this stuff when we give code with holes to be filled by students.

Also I'd vote for NotYetImplementedException.

Sébastien

[Kevin Wright]

I'm actually swinging ever more in favour of @Todo, the more I think about it.

Granted, it requires additional support, but it *does* come with the advantage that the generated message could embed the method name in question... Unless this is something that the upcoming reflection library could also handle, in which case I'm dead set against to any unnecessary changes in the compiler :)

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Jason Zaugg]

On Sun, Oct 2, 2011 at 9:32 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> I'm actually swinging ever more in favour of @Todo, the more I think about
> it.
> Granted, it requires additional support, but it *does* come with the
> advantage that the generated message could embed the method name in
> question... Unless this is something that the upcoming reflection library
> could also handle, in which case I'm dead set against to any unnecessary
> changes in the compiler :)

You might want to use this for branches of a conditional or a match,
rather than an entire method body. Scala allows us to define this as a
method; we should take advantage of that. Mark it as @deprecated and
we get the compile time warnings for free (albeit through an abuse of
that mechanism.) The location of the unimplemented code is captured in
the stack trace of the thrown exception.

Oh, and for the record, I quite like ???.

-jason

[Andrew Forrest]

On 02/10/2011 18:58, Jon Steelman wrote:

Perhaps you would like UnimplementedException over NotYetImplementedException?

.NET BCL uses ‘NotImplementedException’ (to mean the same thing: something which does not yet have an implementation, but which should do). Might be good to use the same name for the same concept?

–Andrew

[Heiko Seeberger]

Such a lively discussion about such a small feature …

Nevertheless I like it. Go for ???. Or TODO, because that's familiar for lots of Java developers. Both are unlikely to be used for any real-world cases. ToDo looks like something someone might actually want to come up with, for example in an application for … a todo list.

Heiko

--

Heiko Seeberger
Twitter: hseeberger
Blog: heikoseeberger.name
Company: Typesafe - Enterprise-Grade Scala from the Experts
Author of Durchstarten mit Scala, a German tutorial-style Scala book

[Daniel Spiewak]

I have actually used ToDo as a valid identifier in an application.  TODO is also a potentially useful identifier when working with Java.  However, ??? is pretty much guaranteed never to be used by any sane-thinking library designer, so I'm going to come out in favor of it just on that basis alone.  Normally, I'm pretty opposed to gratuitous operator overloading.  However, in this case, an operator is the best choice precisely because it is normally the worst choice.  The point is to be unambiguously unusual, and this fits the bill.

I'm pretty strongly opposed to @Todo.  I'm opposed to annotations in general, but this one would be particularly onerous since it adds a type rule associated with the annotation (at least two rules, actually).  We already have a few others that do this (@BeanProperty, @deprecated), and I really would be much happier if we didn't compound the issue by adding another.  The advantage of having the compiler warn in this case is far outweighed by the fact that you would be adding complexity to the core language.  Grep is easy to use, and I think we're all in agreement that ??? is a fairly distinct token (more distinct, in fact, than TODO).

Daniel

[etorreborre]

Just to add my voice to the concert:

• I prefer ??? over TODO or ToDo

• I like the proposal to have ??? as an alias of "undefined" and a simple UndefinedException being thrown. I think this is where we would get good inspiration from Haskell and we could reuse the "undefined" behavior in lots of expressions to show the effects of laziness for example. To me, ??? is more than just "NotYetImplemented"

• ??? is not used in specs/specs2 (and not used in any specification I read)

Eric.

[Daniel Spiewak]

I did a recursive grep (well, ack actually) over my entire hard drive looking for ???.  Now, I don't have everything in the Scala ecosystem just living on my system, but I do have a pretty sizable sampling.  Enough to discover interesting things though (like the fact that Akka's only use of the token is in a FIXME comment that may or may not still be current).

Results: the only Scala project I have that uses ??? as an identifier is Scala itself, and I'd be willing to bet that's all Martin's doing.  (the definitions are equivalent to what he was proposing for Predef)

Daniel

[Paul Phillips]

Since there's still a little patch of bikeshed where I can see the
original wood, I'll retract my preference for ToDo and jump on the ???
bandwagon. I was only trying to do my part not to add any more
symbolic notation to the default namespace. Now I understand that
there's still plenty of room at the top. Preference noted.

Also, we obviously can't ship ??? without its complement.

def ¿¿¿(body: => Any) =
try { body; false }
catch { case _: NotYetImplementedException => true }

[Jorge Ortiz]

I'm strongly opposed to calling it ???. The jokes about Google queries just write themselves: "Scala ???".

I'm mildly opposed to putting it in Predef. There should be fewer things in Predef, not more.

Other than that, I'm a big fan of TODO and frequently use it in my own code.

--j

[Jorge Ortiz]

To fan the flames a little more:

This is exactly what people mean when they talk about Scala being "complex". It does not add any Martin-complexity (the spec doesn't need to change to support this), but it adds normal-people-complexity (there's a mysterious symbol that makes any piece of code magically compile, but I can't Google it to find out how it's actually working).

--j

[Ismael Juma]

On Tue, Oct 4, 2011 at 12:51 AM, Jorge Ortiz <jorge...@gmail.com> wrote:
> To fan the flames a little more:
> This is exactly what people mean when they talk about Scala being "complex".
> It does not add any Martin-complexity (the spec doesn't need to change to
> support this), but it adds normal-people-complexity (there's a mysterious
> symbol that makes any piece of code magically compile, but I can't Google it
> to find out how it's actually working).

If "???" gets added to Predef, a lot of hours will be spent explaining
the reasoning in countless discussions (in the mailing list and
otherwise). It will be /: (foldLeft) all over again. Just worse. Do
people really believe it's worth it?

Best,
Ismael

[Paul Phillips]

On Mon, Oct 3, 2011 at 4:57 PM, Ismael Juma <ism...@juma.me.uk> wrote:
> If "???" gets added to Predef, a lot of hours will be spent explaining
> the reasoning in countless discussions (in the mailing list and
> otherwise). It will be /: (foldLeft) all over again. Just worse. Do
> people really believe it's worth it?

It could be treated as a zen koan.

Student: What does "???" mean?
Master: [silence]
Student: What does "???" mean???
Master: [silence]
Student: I have achieved enlightenment.

Personally I don't want to add anything to Predef until there are
better means of controlling what you get unasked from Predef.

Maybe the mystery of ??? would be reduced if there were only a one
argument version: no zero argument version. Then at least it would
usually say something like

def method = ???("???")

which is much less enigmatic.

[Heiko Seeberger]

> If "???" gets added to Predef, a lot of hours will be spent explaining
> the reasoning in countless discussions (in the mailing list and
> otherwise). It will be /: (foldLeft) all over again. Just worse. Do
> people really believe it's worth it?

No. Every project that likes ??? or TODO to ToDo or FightFoo could add it to its "top level package object" (one good reason to create one, if not already there).

Heiko

[Archontophoenix Quar]

People who don't understand ??? aren't reading enough comics.

A

[martin odersky]

My main point is that I want to use it as an effective teaching tool.

In that case any import/package level object definition destroys the
flow. When teaching I want to start from zero, and introduce only
things that people can reproduce without excessive boilerplate.

Cheers

-- Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Matthew Pocock]

I like the idea of ??? for things that aren't implemented yet. I don't like the idea of further bloating predef, and I definitely think that if it is added, it should be supported by scalac switches so that when they are thrown, any remaining ??? breaks compilation.

Can we possible to put ??? (and any related operators) into their own DSL object that people can explicitly import?

Matthew

--

Dr Matthew Pocock

Visitor, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

tel: (0191) 2566550

mob: +447535664143

[Erik Osheim]

On Tue, Oct 04, 2011 at 09:02:58AM +0200, martin odersky wrote:
> In that case any import/package level object definition destroys the
> flow. When teaching I want to start from zero, and introduce only
> things that people can reproduce without excessive boilerplate.

The ??? isn't the only case where this is a problem. There are lots of
other places in my Scala code where I have to do imports or annotations
which "destroy the flow". Some examples I can think of:

1. import scala.math.Numeric.ExtraImplicits._

Numeric is pretty unusable unless you can use infix operators. The
only ways to accomplish this stills adds import boilerplate to every
file or (worse) every use of a numeric type parameter.

2. import Predef.{any2stringadd => _}

When using my own Numeric I have to disable any2stringadd, this is
another per-file piece of boilerplate.

3. @specialized T:Numeric

When using a specialized Numeric type class, you have you annotate
every type parameter with specialized or else you lose the speed
benefits of specialization. This is *really* ugly!

#1 is not so bad, until you consider that you probably also had to
import scala.math.Numeric itself, so that's two lines. #3 is worse
because it's such a weird-looking import and most people don't have any
idea what it's doing.

#3 is the worst. Given that you need to specialized throughout your
critical path to see performance benefits, this ensures that all your
code becomes clunky and harder to read. Also it's easy to leave this
off by accident.

I am not arguing against ??? per se, but given that other stuff in
Predef is giving me headaches (see 2) I guess I resent the fact that
we're willing to make Predef bigger to prevent having to do a single
import. Other Scala patterns require much more onerous boiler-plate,
with no reprieve in sight.

-- Erik

[jfager]

I agree with Jorge: "I want to use it as an effective teaching tool"
seems at odds with the fact that '???' is incompatible with search
engines. Not everyone learns in a classroom.

For the general functionality, I vote for 'undefined'. It's boring
and doesn't visually stand out as much (though I've never had trouble
with it in Haskell), but it's general, its meaning is clear, and it's
searchable. 'TODO' is slightly more exciting and stands out better,
but it carries extra connotation that may be inappropriate for some
use cases (something can be undefined without actually requiring
additional action). If that extra connotation is desired, then my
vote is for 'TODO' with some kind of compiler support to emit
warnings.

Best,
Jason

[Lieven Lemiengre]

I agree, actually it should be undefined() since the function has side-effects.

Lieven

[Daniel Spiewak]

Actually, it's not a side-effecting function since its result (_|_) is referentially transparent.  Slightly unintuitive, but true.  Another way of thinking about this is looking at Nil.head, which is a pure function that throws an exception.

Daniel

[Adriaan Moors]

On Tue, Oct 4, 2011 at 5:49 PM, Daniel Spiewak <djsp...@gmail.com> wrote:

a pure function that throws an exception

... is not a pure function -- at least not for the definition of "pure" that I'm used to

from the same book of definitions, throwing an exception is considered an effect (the throws clause in Java is actually part of a lightweight type and effect system)

the non-terminating term _|_ is actually from the "impure fragment" of Haskell, and it can also be tracked by an effect system, but lets not go there (tangentially, for the logic corresponding to Haskell's type system to be consistent, you need to disregard bottom [http://www.haskell.org/pipermail/haskell-cafe/2007-October/033580.html], so it certainly has the bitter flavour of impurity to it)

[Daniel Spiewak]

Oooh, meta-theory!

Bottom's inconsistency is a problem more general than simply Haskell.  We can view _|_ as the value which corresponds to the type, (forall a . a).  By the Curry-Howard isomorphism (in its binary logical incarnation), this is the same as saying that we have a proof for every proposition.  So, any language which has _|_ must have an inconsistent logic according to a strict interpretation of CH.  I've always found this just a little annoying, which is why I carefully specified "binary logical incarnation".  However, we're drilling way down into the weeds here!

The larger question is whether or not _|_ represents an impure fragment.  I'm still strongly of the opinion that the answer here is "no".  While it is certainly possible to encode exceptions as effects, it is not necessary.  For example, a monadic encoding of exceptions would be pure and trivially isomorphic to checked exceptions in Java (though with a lot more control over the composition).  This alone implies that _|_ at least has a trivial pure encoding, which suggests that _|_ itself may be pure.

Some of this depends on your perspective.  Referential transparency is of course the defining property of purity, and referential transparency does have a very strong definition.  _|_ on the other hand is a little weird, since it is a value which corresponds to forall a . a, which is to say it is not a value at all.  This would seem to imply that we cannot reason about it directly in terms of referential transparency since the definition requires a value to even make sense.

I think in order to really have this argument properly, we would need to split exceptions from non-termination.  We're overloading _|_ too much, and that's muddying the waters.  I tend to think of exceptions in terms of their monadic encoding, by which definition throw becomes a pure operation as it is referentially transparent (it always produces the same result given the same exception).  I tend to think of _|_ as the value corresponding to non-termination, which is to say not a value at all and thus not pure, but also not impure.  Turing Compute systems really suck.

Anyway, I think we've largely derailed this thread.  Sorry everyone!

Daniel

[Jorge Ortiz]

And herein lies the fundamental problem with Predef.

The Predef appropriate for a classroom is not the Predef appropriate for an industrial setting is not the Predef appropriate for high-performance numerical computing is not the Predef appropriate for...

[martin odersky]

On Tue, Oct 4, 2011 at 9:42 PM, Jorge Ortiz <jorge...@gmail.com> wrote:
> And herein lies the fundamental problem with Predef.
> The Predef appropriate for a classroom is not the Predef appropriate for an
> industrial setting is not the Predef appropriate for high-performance
> numerical computing is not the Predef appropriate for...

Sure. So we need a compromise. But there's value in standardizing,
too. My reaction is the usual: Make simple things easy and hard things
possible.

-- Martin

[Matthew Pocock]

Hi Martin,

On 4 October 2011 20:47, martin odersky <martin....@epfl.ch> wrote:

Sure. So we need a compromise. But there's value in standardizing,
too.

I agree, but that doesn't necessarily mean a single, monolithic predef. It already gets in the way with things like the StringAdd pimp and + operator - makes sense form a Java compatibility point of view, but has lead to so many compilation and/or run-time errors for me. The proposal to add ??? to predef is in itself not that objectionable to me. It's more that it's the straw that breaks the camel's back. 

 

My reaction is the usual: Make simple things easy and hard things
possible.

This is a philosophy that I do agree with, but at some point it's necessary to recognise that one size does not fit all, and that the base-level environment needed for teaching, rapid prototyping, developing stable code (and perhaps other development profiles) are all different and are not monotonic extensions of one-another. The current monolithic predef doesn't support us in recognising this. I see this discussion as intimately related to the idea of modularising the core library.

As a straw-man example, the portions of the predef that makes scala behave a bit like Java (e.g. + coercion to string), together with the implicits for translating between java and scala collections could be bundled up into a 'java interoperability' package object. Those coming from Java would be encouraged to say: import scala.javaInterop, and as they become more confident, they will learn to use the specific imports for the specific interop they require.

I guess the question I'm posing is this: what portions of predef frame scala as a language, and what portions of it are there because most people will probably want it, so by putting it in predef we avoid them typing the same import into each file? For example, is the collections aliasing a convenience to let people not explicitly import the immutable collections or is it part of setting up the language to preferentially support immutable collections? If it's just a convenience, then I'd be for loosing it from a predef-lite and shifting it into a scala.collections package object. If it's part of what makes scala feel like scala to the coder, then it should stay in predef.

 -- Martin

Matthew

[Joni Freeman]

Just want to point out that this function has uses outside of teaching too.
Sometimes it is nice to develop an algorithm top-down. Breaking the algorithm
to smaller functions, typing them and stubbing with undefined body. Those
undefined functions can be then implemented later when everything typechecks.

I quite like the name ???.

Cheers Joni

[Sébastien Bocq]

+1 for ???. I don't see how one more operator can dramatically affect Scala's perceived complexity. If one sees code like this:

def foo() = ???

It is not too difficult to guess from the context that ??? means that the implementation is missing. Besides that, it is much easier to type than ToDo and since I'm using this a lot, it'll make me a more productive programmer :)

2011/10/5 Joni Freeman <freema...@gmail.com>

--
Sébastien

[Alois Cochard]

Hello,

Just add my 2 cents... This really a feature I would love to have, and
love to use.

But honestly guys, what's the point of defining on operator for this ?
what's the advantage of using an operator instead of a named
function ?
Expect making Sébastien making less effort on his keyboard (which is a
totally subjective point) ... I really don't get the point, someone
can en-light me ?

Objectively, it's just certain that this will make newcomer drive
nuts, it's impossible to "google" for an operator and it's not AT ALL
self-explanatory.

On Oct 5, 11:30 am, Sébastien Bocq <sebastien.b...@gmail.com> wrote:
> It is not too difficult to guess from the context that ??? means that the
> implementation is missing.

Come on! tell me your kidding please...

So it's easy to give you lot of advantage about NOT using an operator,
but can someone give me some advantage of using one (in this specific
context of course) ?

Thanks,

--
Alois Cochard
http://www.twitter.com/aloiscochard
http://aloiscochard.blogspot.com

[Ittay Dror]

+1.

for me '???' "sounds" like "wtf?".

I think an 'error("TODO")' is clearer. Especially for newcomers.

[Jeff Olson]

I noticed that there already exists a NotDefinedError in the scala namespace. It is, however, deprecated. I don't know what the history of this class is or why it is deprecated, but it seems like a perfect candidate for the exception thrown by ???. That way we'd only have to undeprecate an already existing name instead of adding a new one. Just a thought.

-Jeff

[Germán Ferrari]

Hi,

I'm also intrigued about why the existing `sys.error("todo")` is not an option.

Regards,
Germán

[Sylvain HENRY]

I think the "newcomers" argument is not relevant. I'm a newcomer when it comes to nuclear physics and I don't expect to understand a paper about it without learning the notation used by nuclear physicists. The same goes for music, mathematics...

-- 
Sylvain HENRY
PhD Student INRIA/LaBRI RunTime Team
Tel: +33 (0)6-70-94-86-76
http://hsyl20.fr

[Ismael Juma]

On Thu, Oct 6, 2011 at 10:09 AM, Sylvain HENRY <hsy...@gmail.com> wrote:
> I think the "newcomers" argument is not relevant. I'm a newcomer when it
> comes to nuclear physics and I don't expect to understand a paper about it
> without learning the notation used by nuclear physicists. The same goes for
> music, mathematics...

I believe we want Scala to be more approachable than nuclear physics.

Best,
Ismael

[Simon Ochsenreither]

I think we have certain people on the mailing list which won't agree with that... :-)

Apart from that I really prefer ???, because it is already widely used. There is a reason why multiple projects without any connection decided to go with ??? and not something else.

If people think there is too much predefined by default, then they should start with throwing out any2stringadd and the lossy numeric conversions first.

[Matthew Pocock]

On 6 October 2011 10:35, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

 

If people think there is too much predefined by default, then they should start with throwing out any2stringadd and the lossy numeric conversions first.

This would make me very happy - these are the sorts of things things I'd personally prefer to have moved out from predef into a 'java-compat-mode-predef' package object that also imports the java collection bridges.

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

[Dave]

I agree

An optional message is handy for tagging the location ??? (like ???
("true branch")) or writing an implementation assignment.
and you don't have to use it.

scala> class NotYetImplementedException(msg: String) extends
Exception(msg)
defined class NotYetImplementedException

scala> def ???(implicit msg : String = "") : Nothing = throw new
NotYetImplementedException(msg)
$qmark$qmark$qmark: (implicit msg: String)Nothing

scala> ???
NotYetImplementedException:
at .$qmark$qmark$qmark(<console>:8)
at .<init>(<console>:10)
at .<clinit>(<console>)
at .<init>(<console>:11)
at .<clinit>(<console>)
at $print(<console>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:601)
at scala.tools.nsc.interpreter.IMain
$ReadEvalPrint.call(IMain.scala:704)

at scala.tools.nsc.interpreter.IMain$Request$$anonfun
$14.apply(IMain.scala:920)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV
$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:25)
at java.lang.Thread.run(Thread.java:722)

scala> def m(test: Boolean) = {
| if(test) ???("Implement true")
| else ???("Implement false")
| }
m: (test: Boolean)Nothing

scala> m(true)
NotYetImplementedException: Implement true
at .$qmark$qmark$qmark(<console>:8)
at .m(<console>:10)
at .<init>(<console>:11)
at .<clinit>(<console>)
at .<init>(<console>:11)
at .<clinit>(<console>)
at $print(<console>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:601)
at scala.tools.nsc.interpreter.IMain
$ReadEvalPrint.call(IMain.scala:704)

at scala.tools.nsc.interpreter.IMain$Request$$anonfun
$14.apply(IMain.scala:920)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV
$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:25)
at java.lang.Thread.run(Thread.java:722)


scala> m(false)
NotYetImplementedException: Implement false
at .$qmark$qmark$qmark(<console>:8)
at .m(<console>:11)
at .<init>(<console>:11)
at .<clinit>(<console>)
at .<init>(<console>:11)
at .<clinit>(<console>)
at $print(<console>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:601)
at scala.tools.nsc.interpreter.IMain
$ReadEvalPrint.call(IMain.scala:704)

at scala.tools.nsc.interpreter.IMain$Request$$anonfun
$14.apply(IMain.scala:920)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV
$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:25)
at java.lang.Thread.run(Thread.java:722)





On 1 okt, 20:40, Simon Ochsenreither
<simon.ochsenreit...@googlemail.com> wrote:
> I would suggest ??? with an optional message.
>
> While ‘ToDo’ and others could work too, the fact that almost everybody out
> there took ??? instead of those speaks for itself.

[Adam Jorgensen]

I don't agree because I think def x = ??? is a pretty obvious placeholder for things to come.

On the other hand the points about a classroom Predef vs a real-world Predef are quite relevant.

On 4 October 2011 01:51, Jorge Ortiz <jorge...@gmail.com> wrote:

To fan the flames a little more:

This is exactly what people mean when they talk about Scala being "complex". It does not add any Martin-complexity (the spec doesn't need to change to support this), but it adds normal-people-complexity (there's a mysterious symbol that makes any piece of code magically compile, but I can't Google it to find out how it's actually working).

--j

On Mon, Oct 3, 2011 at 7:46 PM, Jorge Ortiz <jorge...@gmail.com> wrote:

I'm strongly opposed to calling it ???. The jokes about Google queries just write themselves: "Scala ???".

I'm mildly opposed to putting it in Predef. There should be fewer things in Predef, not more.

Other than that, I'm a big fan of TODO and frequently use it in my own code.

--j

On Mon, Oct 3, 2011 at 7:32 PM, Paul Phillips <pa...@improving.org> wrote:

Since there's still a little patch of bikeshed where I can see the
original wood, I'll retract my preference for ToDo and jump on the ???
bandwagon.  I was only trying to do my part not to add any more
symbolic notation to the default namespace.  Now I understand that
there's still plenty of room at the top.  Preference noted.

Also, we obviously can't ship ??? without its complement.

 def ¿¿¿(body: => Any) =
   try   { body; false }
   catch { case _: NotYetImplementedException => true }

[martin odersky]

Thanks for all the responses. It's hard to gauge the majority opinion
in situations like this (people always seem to come out more numerous
to oppose what's proposed than to support it). I think I could read
that ??? has majority support but people clearly wanted a different
exception than UnsupportedOperationException to be thrown.

I know about the dangers of symbolic operators very well. But in this
case I think we have a genuine case of a useful symbolic operator, so
I am going to stick with it.

I just added the following to Predef:

/** `???` can be used for marking methods that remain to be implemented.
* @throws A `NotImplementedError`
*/
def ??? : Nothing = throw new NotImplementedError

Best,

-- Martin

[Simon Ochsenreither]

What about allowing an optional exception message?

Would be quite handy for teaching imho ...

[Louis Botterill]

great stuff, I like it personally, ??? stands out and a new error type makes total sense too. An optional param for a message could also be useful in some situations, since say calling a service over a remote interface and getting a meaningful exception with a small message could be very handy. Anyway thumbs up from me, I really like the top down coding style in many situations, this will be perfect for that sort of thing.

[Jon Steelman]

Yes, for example:

  def reflect = ???  "Martin promised to finish reflection by Halloween"

Thanks,

Jon

[martin odersky]

On Fri, Oct 7, 2011 at 7:23 PM, Simon Ochsenreither
<simon.och...@googlemail.com> wrote:
> What about allowing an optional exception message?
>

How would you add that to ???. Two overloaded variants?
Note that one can alreayd write:

throw new NotImplementedError(msg)

I generally don't see a strong need for an additional message because
??? should be a stand-in for something you intend to implement before
you run the program. So why bother adding a message?

-- Martin

[Som Snytt]

On Fri, Oct 7, 2011 at 10:32 AM, Louis Botterill <chillip...@gmail.com> wrote:

great stuff, I like it personally, ??? stands out and a new error type makes total sense too. An optional param for a message could also be useful in some situations, since say calling a service over a remote interface and getting a meaningful exception with a small message could be very handy. Anyway thumbs up from me, I really like the top down coding style in many situations, this will be perfect for that sort of thing.

Me, too. +1.

I'd have gone with UnimplementedOperationException.  If it's an Error, an otherwise "reasonable application" such as some TA's ClassAssignmentRunner will have to catch it in order to fail(exercise).

A couple of people mentioned top-down style; I'd add that it goes to Scalability.  I looked at the slides someone pointed to, and coded the example as an exercise in TDD style: ??? is a very nice placeholder, vi-friendly (in the absence of code completion).  I will use it on an everyday basis.

It would be nice if there were a way to make it break the build, so I don't do anything stupid.  My first thought was something like @elidable, so I could raise the elision level for testing. Perhaps it would be nice to have it elide to something that necessarily fails to compile.  @elidabe(broken=true).

[Chris Twiner]

Sometimes people forget to implement things, especially if they didn't think they would be called just yet.

I had understood that to be kinda the point for this, the I'll get around to this later sentiment.

I'd vote for a default parameter with a simple empty string.

[Paul Phillips]

On Fri, Oct 7, 2011 at 11:18 AM, Chris Twiner <chris....@gmail.com> wrote:
> I'd vote for a default parameter with a simple empty string.

def foo = ???() kind of blows the vibe, doesn't it.

If you want to be able to call it without parens, it has to be an
implicit parameter, ha ha. Otherwise it's time to enlist mr.
overload.

[Simon Ochsenreither]

Is there a reason why it is an Error instead of an Exception? Error has a very specific meaning in a JVM context ... I'm not sure the proposed usage reflects that.
Afaik an Error is supposed to mean “The JVM just broke and there is nothing vou can do, but instead of crashing immediately we try to give you a hint what happened.”, e. g. OutOfMemoryError.

Or is it just so that people catching Exceptions don't swallow this error?


Thanks and bye,


Simon

[martin odersky]

I reasoned that a failed assertion also gives an error, and a missing
implementation is closest to a failed assertion.

Cheers

-- Martin

[√iktor Ҡlang]

On Sun, Oct 9, 2011 at 1:09 PM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

Is there a reason why it is an Error instead of an Exception? Error has a very specific meaning in a JVM context ... I'm not sure the proposed usage reflects that.
Afaik an Error is supposed to mean “The JVM just broke and there is nothing vou can do, but instead of crashing immediately we try to give you a hint what happened.”, e. g. OutOfMemoryError.

I think you're confusing Error with VirtualMachineError: http://download.oracle.com/javase/7/docs/api/java/lang/VirtualMachineError.html

 

Or is it just so that people catching Exceptions don't swallow this error?


Thanks and bye,


Simon

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[etorreborre]

Simon's understanding of Error is close to mine. The javadoc says:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Errorbecause most applications should not try to catch it.

"NotImplemented" may be perfectly recoverable and I'd rather have that as an exception, a bit like java.lang.UnsupportedOperationException.

Eric.

[Kevin Wright]

Only if you truly consider a big chunk of missing implementation to be a problem from which an application could reasonably be expected to recover...  I'd say the jury's out on that one!

[etorreborre]

I was thinking that you could switch implementations if one implementation of an interface is not provided for your context.

[Christos KK Loverdos]

+1

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

[Louis Botterill]

FWIW, particularly in a bigger project perhaps between teams, I sometimes deliver a partially implemented interface, with the rest to follow in a later drop - so for that reason providing a message in a standard way could be handy (but it's not a massive deal). So there's no really easy/neat way to handle an arg-less function with an overloaded variant without having to use empty parens on the no-arg version?

[Francois]

On 10/10/2011 04:51, etorreborre wrote:

I was thinking that you could switch implementations if one implementation of an interface is not provided for your context.

Shouldn't that be part of the application logic, with it's own exception for that ? I understood that "???" would be reserved for the unexpected missing implementation, in a oups-I-forgot-to-finish-my-implementation-after-coming-back-from-coffee way.

Thinking about that: Scala IDE may propose an "implement these traits" menu which would put "???" as body of method to implements.

Cheers,

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[martin odersky]

On Mon, Oct 10, 2011 at 4:51 AM, etorreborre <etorr...@gmail.com> wrote:
> I was thinking that you could switch implementations if one implementation
> of an interface is not provided for your context.

I believe in that case the implementation should throw an
UnSupportedOperationException, not a NotImplementedError.
NotImplementedError is really akin to assert(false) and should be
treated that way.

-- Martin

[Patrik Andersson]

But isn't a method that has yet to receive implementation really much more serious in nature than a bad assertion? ??? is intended to be used as stubbed-out method bodies, no? A call-path that sinks at ??? is very serious - it needs immediate attention as the program is not (yet) complete. It's the big hole in the middle of a street - not an indication of: please choose an alternate route.

    Patrik