June 26, 2012
On Tue, 26 Jun 2012 02:50:46 +0100, Kapps <opantm2+spam@gmail.com> wrote:

> Any reason that just using mixin(import("myclass.partial.d")) wouldn't work?

It /could/ work if you were careful about what you were mixing in, and into what.  In C# partial classes look like this (bare minimum).

[File1]
partial class Foo
{
}

[File2]
partial class Foo
{
}

And then, for example, the form builder gui would automatically add members and methods to File1 while user created content would be added by the user to File2.  At compile time, the two files are compiled as one class.

Alternately File1 may be produced by a tool like sqlmetal once, or multiple times while the user added content in File2 would remain completely under the users control.

So, yes, in D we could have:

[File1]
partial class Foo
{
 .. compiler/form builder content ..
mixin(import("File2.d"))
}

[File2]
void foo()
{
}

But, note how File2 does not (cannot) have the class declaration, etc.  Alternately you could go the other way..

[File1]
partial class Foo
{
  .. user content ..
  mixin(import("File2.d"))
}

[File2]
.. compiler/form builder content ..

So the compiler file has no class declaration, but then the user would have to be careful not to remove the mixin.

Either way, it's just not quite as "nice" as the C# feature.

Implementing the C# feature in D could be trivial with some limitations.  i.e.

1. Partial classes must be in similarly named files i.e. foo_1.d and foo_2.d (where foo is user defined by _1 and _2 are mandatory).

2. Partial classes must be compiled on the same command line and produce foo.o (note _1 and _2 are dropped and only 1 object file is produced).

.. and so on.  I am no expert on compiling/linking so there may be complications to the feature, but essentially it could be as simple as compiling the first file, pretending you haven't seen the } ending the class definition, opening the next file and ignoring the "partial class" line and continuing as if they were 1 file.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
June 26, 2012
On 2012-06-26 01:43, Walter Bright wrote:

> Monkey-patching has, in Ruby, been popular and powerful. It has also
> turned out to be a disaster. It does not scale, and is not conducive to
> more than one person/team working on the code base.

I have only found it being very useful. I have never found it to be a disaster. Have you ever used Ruby?

Ruby on Rails has to be the most popular Ruby library/framework and it adds a lot of new functionality to existing classes in the standard library.

But just as with everything else you have to be responsible. In Ruby you can replace arbitrary methods and classes, even in the standard library. In D you can overwrite an arbitrary piece of memory.

-- 
/Jacob Carlborg
June 26, 2012
On 2012-06-25 23:26, Manu wrote:

> And that's basically the limitation I'd like to overcome. The fact
> something needs to be designed for it in advance; that is completely
> unrealistic.
> No 3rd party can ever anticipate what you might want to do. Whether you
> want to unintrusively extend some existing code, or you provide a
> library which can extend things in a general way.. If you can craft your
> partial extension in such a way than it integrates neatly with the 3rd
> party stuff you're using, that seems like a much more sensible approach,
> since it leaves the customisation to you, rather than the original
> author to attempt to anticipate...
>
> I really hate it when I have to butcher 3rd party code to add my bits.
> It makes it hard to maintain, if the author updates the code. Much nicer
> to extend it with my bit as a partial, and keep my code clinically
> separated.

Isn't it the same with partial classes? What if the third party class hasn't been marked with "partial".

-- 
/Jacob Carlborg
June 26, 2012
On 6/26/2012 3:53 AM, Jacob Carlborg wrote:
> On 2012-06-26 01:43, Walter Bright wrote:
>
>> Monkey-patching has, in Ruby, been popular and powerful. It has also
>> turned out to be a disaster. It does not scale, and is not conducive to
>> more than one person/team working on the code base.
>
> I have only found it being very useful. I have never found it to be a disaster.
> Have you ever used Ruby?

Not much, but I've read accounts from people who have who say that monkey-patching doesn't scale.


> Ruby on Rails has to be the most popular Ruby library/framework

PHP is popular, too.


> and it adds a
> lot of new functionality to existing classes in the standard library.
>
> But just as with everything else you have to be responsible.

A language should not encourage bad behavior, nor should it make code unreasonably difficult to reason about.


> In Ruby you can
> replace arbitrary methods and classes, even in the standard library. In D you
> can overwrite an arbitrary piece of memory.

Not when using safe code, you can't.


June 26, 2012
On 06/26/12 20:21, Walter Bright wrote:
> On 6/26/2012 3:53 AM, Jacob Carlborg wrote:
>> replace arbitrary methods and classes, even in the standard library. In D you can overwrite an arbitrary piece of memory.
> 
> Not when using safe code, you can't.

   void poke(T)(size_t addr, T val) @safe pure {
      T* ptr;
      ptr[addr/T.sizeof] = val;
   }

   int i = 42;

   void main() @safe {
      writeln(i);
      auto whatever = cast(size_t)&i;
      poke(whatever, 666);
      writeln(i);
      poke(0, 0);
   }

   void writeln(A...)(A a) @trusted { import std.stdio; writeln(a); }

artur
June 26, 2012
On 06/26/2012 09:29 PM, Artur Skawina wrote:
> On 06/26/12 20:21, Walter Bright wrote:
>> On 6/26/2012 3:53 AM, Jacob Carlborg wrote:
>>> replace arbitrary methods and classes, even in the standard library. In D you
>>> can overwrite an arbitrary piece of memory.
>>
>> Not when using safe code, you can't.
>
>     void poke(T)(size_t addr, T val) @safe pure {
>        T* ptr;
>        ptr[addr/T.sizeof] = val;
>     }
>
>     int i = 42;
>
>     void main() @safe {
>        writeln(i);
>        auto whatever = cast(size_t)&i;
>        poke(whatever, 666);
>        writeln(i);
>        poke(0, 0);
>     }
>
>     void writeln(A...)(A a) @trusted { import std.stdio; writeln(a); }
>
> artur

This is not legal D code. (pointer indexing is unsafe)
June 26, 2012
On 6/26/2012 12:52 PM, Timon Gehr wrote:
> On 06/26/2012 09:29 PM, Artur Skawina wrote:
>> On 06/26/12 20:21, Walter Bright wrote:
>>> On 6/26/2012 3:53 AM, Jacob Carlborg wrote:
>>>> replace arbitrary methods and classes, even in the standard library. In D you
>>>> can overwrite an arbitrary piece of memory.
>>>
>>> Not when using safe code, you can't.
>>
>>     void poke(T)(size_t addr, T val) @safe pure {
>>        T* ptr;
>>        ptr[addr/T.sizeof] = val;
>>     }
>>
>>     int i = 42;
>>
>>     void main() @safe {
>>        writeln(i);
>>        auto whatever = cast(size_t)&i;
>>        poke(whatever, 666);
>>        writeln(i);
>>        poke(0, 0);
>>     }
>>
>>     void writeln(A...)(A a) @trusted { import std.stdio; writeln(a); }
>>
>> artur
>
> This is not legal D code. (pointer indexing is unsafe)

If the compiler doesn't give an error on that, it's a compiler bug, not a language problem.

1 2
Next ›   Last »