Kagamin Wrote:

> Denis Koroskin Wrote:
> 
> > class Widget
> > {
> >     WidgetFactory* factory = &defaultFactory;
> > }
> > 
> > void main()
> > {
> >     Widget w = new Widget();
> >     writefln(w.factory.someParameterValue); // prints 14
> > }
> 
> You initialize member field here. It's usually done in instance constructor.
> 
> class Widget
> {
>     WidgetFactory factory;
>     this(){ factory = defaultFactory; }
> }

I don't agree with you. If so, then why we have the following syntax allowed:

class Foo
{
    int i = 42;
}

if we could just use

class Foo
{
    this()
    {
        i = 42;
    }
}

?

Imagine you have lots of ctors (with different arguments), should you put i = 42; into every one? Or move it into some initialize() method? Don't you think it is too verbose?

Denis Koroskin Wrote:

> I don't agree with you. If so, then why we have the following syntax allowed:
> 
> class Foo
> {
>     int i = 42;
> }

It fits well into .init feature. If you want to split constructor, some subtle bugs can arise. For example one programmer stumbled into such bug in Java: base class constructor was called, it called virtual method, overriden in derived class, this method assigned an object to a field, then base class constructor returned and derived field initializers were called and they assigned null to that field, so object ended up with null in the field.

Weed Wrote:

> > I'd prefer run-time checks, though
> > templates can be used for sure.
> 
> This problem would help solve the availability of inheritance for structs or compile-time creation of class instances.

I see no way, how it can help.

Weed Wrote:

> > I'd prefer run-time checks, though
> > templates can be used for sure.
> 
> This problem would help solve the availability of inheritance for structs or compile-time creation of class instances.

And I see no problem. Absence of compile-time object creation doesn't prevent you from using templates.

Kagamin пишет:
> Weed Wrote:
> 
>>> I'd prefer run-time checks, though
>>> templates can be used for sure.
>> This problem would help solve the availability of inheritance for structs or compile-time creation of class instances.
> 
> And I see no problem. Absence of compile-time object creation doesn't prevent you from using templates.

The problem is not in use templates.

Templates are implementing some of the functionality of 2 types of structures matrices (normal and dynamic). But the structures do not inherit, then to add functionality matrix to other entities ( "pixel", "image" etc) sites will have their list in a template return type.

For example:
http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d

see template MultReturnType(ArgT)

It contain list of all types (MatrixT and VectorT) for return. Will it add types of "image" and "pixel" and still others if needed. This is as good as manually implement a new object model.

It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.

Weed Wrote:

> The problem is not in use templates.
> 
> Templates are implementing some of the functionality of 2 types of structures matrices (normal and dynamic). But the structures do not inherit, then to add functionality matrix to other entities ( "pixel", "image" etc) sites will have their list in a template return type.

If structs don't suit you, don't use them. Classes are better suited for OOP as I said long ago and continue repeating it over and over.

> It contain list of all types (MatrixT and VectorT) for return. Will it add types of "image" and "pixel" and still others if needed. This is as good as manually implement a new object model.

I'm sure any properly formalized problem is solvable. All you need is proper formalization and some design work.

> It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.

Sure it can't. Does it cause that big problems?

Kagamin пишет:
> Weed Wrote:
> 
>> The problem is not in use templates.
>>
>> Templates are implementing some of the functionality of 2 types of structures matrices (normal and dynamic). But the structures do not inherit, then to add functionality matrix to other entities ( "pixel", "image" etc) sites will have their list in a template return type.
> 
> If structs don't suit you, don't use them. Classes are better suited for OOP as I said long ago and continue repeating it over and over.
> 
>> It contain list of all types (MatrixT and VectorT) for return. Will it add types of "image" and "pixel" and still others if needed. This is as good as manually implement a new object model.
> 
> I'm sure any properly formalized problem is solvable. All you need is proper formalization and some design work.
> 
>> It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.
> 
> Sure it can't. Does it cause that big problems?

Sometimes it is the only way to avoid a large number of global ad

Weed Wrote:

> >> It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.
> > 
> > Sure it can't. Does it cause that big problems?
> 
> Sometimes it is the only way to avoid a large number of global ad

In D module variables can be protected by access modifiers and become module-local.

Weed пишет:
> Kagamin пишет:
>> Weed Wrote:
>>
>>>> I'd prefer run-time checks, though
>>>> templates can be used for sure.
>>> This problem would help solve the availability of inheritance for structs or compile-time creation of class instances.
>>
>> And I see no problem. Absence of compile-time object creation doesn't prevent you from using templates.
> 
> The problem is not in use templates.
> 
> Templates are implementing some of the functionality of 2 types of structures matrices (normal and dynamic). But the structures do not inherit, then to add functionality matrix to other entities ( "pixel", "image" etc) sites will have their list in a template return type.
> 
> For example:
> http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d 
> 
> 
> see template MultReturnType(ArgT)
> 
> It contain list of all types (MatrixT and VectorT) for return. Will it add types of "image" and "pixel" and still others if needed. This is as good as manually implement a new object model.
> 
> It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.

In fact, the minimum number of matrices 3:
dynamic
fixed-size
fixed-size static

The last 2 are different way of storing components - "fixed-size static"  has dynamic array (because compile-time assignment is now does not assign anything to static array) and "fixed-size" it with a static array with size calculated in the template.


I will be happy if someone tells a mistake in the design of my idea :)

Kagamin пишет:
> Weed Wrote:
> 
>>>> It is not necessary to suggest to wrap up "pixel" in a class - then it too cannot be initialized in a compile time.
>>> Sure it can't. Does it cause that big problems?
>> Sometimes it is the only way to avoid a large number of global ad
> 
> In D module variables can be protected by access modifiers and become module-local.

Module full of mathematics turns into horror quite quickly. I have checked this:)