August 30, 2017
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
> On Wednesday, 30 August 2017 at 20:40:38 UTC, Jean-Louis Leroy wrote:
>>
>> After mulling over this example, I don't see how this proves that Julia does *not* support run time polymorphism. On the contrary.

In that case you are right! Julia is doing run-time polymorphism and dynamic multiple dispatch ... because there is no sense in which compile time types exist. Functions are pre-compiled but types are always run time. Phew, I think got there in the end
August 30, 2017
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
> In the light of this I think your package just became more interesting to me.

I think that your work and mine are complementary :-)


August 30, 2017
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>> In the light of this I think your package just became more interesting to me.
>
> I think that your work and mine are complementary :-)

Yes, one of the problems I have been trying to solve is the best way of writing a table structure similar to a data frame in R. Till now polymorphism never really appealed to me but with your package writing methods for such structures become much nicer, a simple prototype could be this:

```
import std.stdio: writeln;

class GenericVector{}
class Vector(T): GenericVector{
	T[] data;
	this(T[] data)
	{
		this.data = data;
	}
}

void main()
{
	GenericVector[] myTable = [new Vector!double([1., 2., 3.]), new Vector!string(["a", "b", "c"])];
	writeln(typeid(myTable[0]));
	writeln(typeid(myTable[1]));
}
```

Then your openmethods package can dispatch on these types of objects. Very cool!
August 30, 2017
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>> In the light of this I think your package just became more interesting to me.
>
> I think that your work and mine are complementary :-)

Here is one strange difference between inheriting from an interface and a class:

```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}


void main()
{
	Animal[] x;
	x ~= new Cat();
	x ~= new Dog();
	x ~= new Cat();
	writeln(typeid(x[0])); // Gives Animal
}
```

But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?

August 30, 2017
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
> On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
>> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>>> In the light of this I think your package just became more interesting to me.
>>
>> I think that your work and mine are complementary :-)
>
> Here is one strange difference between inheriting from an interface and a class:
>
> ```
> interface Animal{}
> class Dog: Animal{}
> class Cat: Animal{}
>
>
> void main()
> {
> 	Animal[] x;
> 	x ~= new Cat();
> 	x ~= new Dog();
> 	x ~= new Cat();
> 	writeln(typeid(x[0])); // Gives Animal
> }
> ```
>
> But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?

Is there a reason you're not using
writeln(typeid(typeof(x[0])));
I pretty much always write it that way.
August 30, 2017
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
> On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
>> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>>> In the light of this I think your package just became more interesting to me.
>>
>> I think that your work and mine are complementary :-)
>
> Here is one strange difference between inheriting from an interface and a class:
>
> ```
> interface Animal{}
> class Dog: Animal{}
> class Cat: Animal{}
>
>
> void main()
> {
> 	Animal[] x;
> 	x ~= new Cat();
> 	x ~= new Dog();
> 	x ~= new Cat();
> 	writeln(typeid(x[0])); // Gives Animal
> }
> ```
>
> But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?

I noticed that too. Still scratching my head.
August 30, 2017
On Wednesday, 30 August 2017 at 22:49:54 UTC, jmh530 wrote:
> On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
>> On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
>>> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>>>> In the light of this I think your package just became more interesting to me.
>>>
>>> I think that your work and mine are complementary :-)
>>
>> Here is one strange difference between inheriting from an interface and a class:
>>
>> ```
>> interface Animal{}
>> class Dog: Animal{}
>> class Cat: Animal{}
>>
>>
>> void main()
>> {
>> 	Animal[] x;
>> 	x ~= new Cat();
>> 	x ~= new Dog();
>> 	x ~= new Cat();
>> 	writeln(typeid(x[0])); // Gives Animal
>> }
>> ```
>>
>> But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?
>
> Is there a reason you're not using
> writeln(typeid(typeof(x[0])));
> I pretty much always write it that way.

typeid() will give you the run-time type while typeof() gives the declared (compile time) type, typeid(typeof()) will not give you the run-time type - which in our case is what we want if we are using sub-typing polymorphism.
August 31, 2017
On Wednesday, 30 August 2017 at 23:45:13 UTC, data pulverizer wrote:
>
> typeid() will give you the run-time type while typeof() gives the declared (compile time) type, typeid(typeof()) will not give you the run-time type - which in our case is what we want if we are using sub-typing polymorphism.

Ah, news to me.

Also, I have pushed my branch of the distributions work I've done to my fork of dstats. I haven't submitted a PR yet because I had submitted some other small fixes and want to see how they go (and maybe adjust some of the work I've done in response).

https://github.com/jmh530/dstats/tree/jmh530-addDistributions
August 31, 2017

On 31.08.2017 01:34, Jean-Louis Leroy wrote:
> On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
>> On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
>>> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>>>> In the light of this I think your package just became more interesting to me.
>>>
>>> I think that your work and mine are complementary :-)
>>
>> Here is one strange difference between inheriting from an interface and a class:
>>
>> ```
>> interface Animal{}
>> class Dog: Animal{}
>> class Cat: Animal{}
>>
>>
>> void main()
>> {
>>     Animal[] x;
>>     x ~= new Cat();
>>     x ~= new Dog();
>>     x ~= new Cat();
>>     writeln(typeid(x[0])); // Gives Animal
>> }
>> ```
>>
>> But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?
> 
> I noticed that too. Still scratching my head.

typeid(Interface) has been subject to a number of bugzilla reports, e.g. https://issues.dlang.org/show_bug.cgi?id=13833 and https://issues.dlang.org/show_bug.cgi?id=14612.
August 31, 2017
On Wednesday, 30 August 2017 at 23:34:10 UTC, Jean-Louis Leroy wrote:
> On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
>> On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
>>> On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
>>>> In the light of this I think your package just became more interesting to me.
>>>
>>> I think that your work and mine are complementary :-)
>>
>> Here is one strange difference between inheriting from an interface and a class:
>>
>> ```
>> interface Animal{}
>> class Dog: Animal{}
>> class Cat: Animal{}
>>
>>
>> void main()
>> {
>> 	Animal[] x;
>> 	x ~= new Cat();
>> 	x ~= new Dog();
>> 	x ~= new Cat();
>> 	writeln(typeid(x[0])); // Gives Animal
>> }
>> ```
>>
>> But if Animal is set to a class the typeid gives Cat, why does this happen? Does this mean that inheriting from an interface is not really polymorphism?
>
> I noticed that too. Still scratching my head.

The workaround is to cast to Object before getting the typeid. The cause for this behavior is that if you have an interface reference to an object it points to the interface vtbl and not to the Object base class vtbl.

https://run.dlang.io/is/3IMrin