Thread overview
Proposal: Support for objects in switch statements
Nov 04
angel
Nov 05
bauss
Nov 07
sarn
November 01
After I started to alter my graphics engine to use the multiple kinds of bitmaps (now using multiple language features, like templates and aliases) on one layer, I noticed that type detection of bitmap objects would be easier and better readable, if instead of:

if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...

I could easily use this:

switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}

On the other hand I cannot really think other uses for such language feature, maybe with structs.
November 01
On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 wrote:
> After I started to alter my graphics engine to use the multiple kinds of bitmaps (now using multiple language features, like templates and aliases) on one layer, I noticed that type detection of bitmap objects would be easier and better readable, if instead of:
>
> if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
> ...
> }else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
>
> I could easily use this:
>
> switch(bitmapObject.classinfo){
> case typeof(Bitmap4Bit):
> ...
> case typeof(Bitmap8Bit):
> }
>
> On the other hand I cannot really think other uses for such language feature, maybe with structs.

Maybe use something similar to recieve()? Like:

match(obj, (Type1 x) => {}, (Type2 x) => {}, ...)
November 04
On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 wrote:
> After I started to alter my graphics engine to use the multiple kinds of bitmaps (now using multiple language features, like templates and aliases) on one layer, I noticed that type detection of bitmap objects would be easier and better readable, if instead of:
>
> if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
> ...
> }else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
>
> I could easily use this:
>
> switch(bitmapObject.classinfo){
> case typeof(Bitmap4Bit):
> ...
> case typeof(Bitmap8Bit):
> }
>
> On the other hand I cannot really think other uses for such language feature, maybe with structs.

The idea IS good, I am sure it has already happened to many.
May it be there are some technical problems with it ?
November 05
On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 wrote:
> After I started to alter my graphics engine to use the multiple kinds of bitmaps (now using multiple language features, like templates and aliases) on one layer, I noticed that type detection of bitmap objects would be easier and better readable, if instead of:
>
> if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
> ...
> }else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
>
> I could easily use this:
>
> switch(bitmapObject.classinfo){
> case typeof(Bitmap4Bit):
> ...
> case typeof(Bitmap8Bit):
> }
>
> On the other hand I cannot really think other uses for such language feature, maybe with structs.

While it's not entirely ideal something like this works.

```
template ClassName(T, string mod = __MODULE__)
{
	enum ClassName = mod ~ "." ~ T.stringof;
}

@property string className(T)(T o)
{
	return o.classinfo.toString();
}
```

Example:

```
final switch (bitmapObject.className)
{
	case ClassName!Bitmap4Bit: ... break;
		
	case ClassName!Bitmap8Bit: ... break;
}
```
November 06
On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 wrote:
> After I started to alter my graphics engine to use the multiple kinds of bitmaps (now using multiple language features, like templates and aliases) on one layer, I noticed that type detection of bitmap objects would be easier and better readable, if instead of:
>
> if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
> ...
> }else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
>
> I could easily use this:
>
> switch(bitmapObject.classinfo){
> case typeof(Bitmap4Bit):
> ...
> case typeof(Bitmap8Bit):
> }
>
> On the other hand I cannot really think other uses for such language feature, maybe with structs.

Checking for types at runtime is a code smell in OOP. Sometimes necessary, especially if doing multiple dispatch, but never done gladly. There's already a way to dispatch on type: virtual functions.

Atila
November 07
On Monday, 6 November 2017 at 10:10:29 UTC, Atila Neves wrote:
> Checking for types at runtime is a code smell in OOP. Sometimes necessary, especially if doing multiple dispatch, but never done gladly. There's already a way to dispatch on type: virtual functions.
>
> Atila

More on that:
https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/

It often happens when people try to model sum types using polymorphism.