Re: Delphi and the .Net platform



Rudy Velthuis [TeamB] a écrit :

Destructors in Delphi for .NET map to IDisposable.Dispose, i.e. not
related to freeing the one resource the GC takes care of, but to
freeing all the other resources one uses. IMO; destructors and Free
make just as much sense in .NET as they do in Win32. They are not just
meant to release memory.

I would disagree that destructors and Free make sense in .NET. The only reason for using the Delphi Free is to ensure unmanaged resources are cleaned up. Most business classes do not implement IDisposable and have no need for unmanaged resources. As I may have mentioned before, in the few hundred classes in our frameworks, we only have one non-component class that implements IDisposable. Any component classes derive from classes that already implement IDisposable and, because they are managed by forms that own them, the call to Dispose is managed automatically by the form.

The false premise of leaving calls to Free in legacy code when it is ported to .NET will lead to errors in GC management, giving the lesser experienced reason to believe that they are still wotking with a deterministic memory model.

I will repeat, for it bears repetition, calling Dispose does not free off memory, all it does is dispose of unmanaged resources whilst leaving the managed part of the object to hang around until the GC passes by. It is still possible to address a disposed object, but you will get all sorts of errors - a bit like addressing a freed, and therefore invalid, object in Win32.

Sure your code may still compile with all those calls to Free left in but, should an old Delphi 32 hacker come along, thinking that things are deterministically finalised the same in .NET, I can see some pretty odd bugs creeping in :-)

I'm actually glad that there is a strict coupling of namespaces and
unit names. This makes the management of code much easier. AFAIK, Java
has a similar concept: file names and class names coincide.

But there isn't a strict coupling between namespaces and unit names - well not completely anyway. The Delphi idea of a namespace is to use all of the unit name up to the last dot. This then means that unit names can get horrendously long as opposed to the C# way of having unit names totally divorced from namespaces, thus allowing a suitably meaningful (usually the class name) short name for the unit whilst declaring the namespace inside the unit. But, hey, what's a name between friends ? :-)

As for Java's restrictions, there are times when you could really do with declaring just a tad more than a sinlge one line interface declaration in one unit, e.g.

//unit name IVisitor.java

package carter.frameworks.patterns;

public interface IVisitor
{
}

//unit name IVisitable.java

package carter.frameworks.patterns;

public interface IVisitable
{
void Accept(IVisitor visitor);
}

Being able to connect two such short declarations in one unit make sense, but not in Java :-(

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
.



Relevant Pages

  • Re: Problem with C# not calling MC++ destrcutor
    ... You should deal with other resources using the dispose pattern in C#. ... At the next garbage collection they will be placed in the queue of object to be finalized, and a background process will call their finalizers eventually. ... If you implement IDisposable, it will make the memory management much more efficient. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: NASAs vision lost on Web generation
    ... Your great concern for the taxpayers is noted. ... Wasting resources doesn't contribute to the greater good. ... contributed to resourced management. ... the books to make the case for shuttle. ...
    (sci.space.shuttle)
  • Re: VIO Server, and virtual resource provisioning
    ... Management is asking ... Then you make another table with the total resources of each managed ... applied toward a spreadsheet as well. ... $lsdev -type disk ...
    (comp.unix.aix)
  • Re: MS Project lacks basic project management features!
    ... I realize that it does not plan for ordering or replenishment of material resources nor does it do any inventory management of materials nor plan production around material availability. ...
    (microsoft.public.project)
  • Re: fixed duration projects
    ... We are saying the same thing - the PM IS the management who's making the decisions that I am referring to. ... Adding resources will not always shorten the duration - pregnancy still takes nine-months and, as modern science has shown, you can now generate as many as eight children with the same amount of Work. ... That means that for other than tasks like staff meetings and the like, as you adjust the number of resources on them they should get longer or shorter depending on whther you're adding or taking away workers. ... And how could a project have a fixed duration when you add or remove tasks? ...
    (microsoft.public.project)