Board index » delphi » Re: Unmanaged Possibilities

Re: Unmanaged Possibilities


2006-04-26 08:17:53 PM
delphi268
Hi!
Quote
Not really. Class constructors come to mind, for example. As with
attributes, these require runtime support that Delphi doesn't provide.
A lot has been done. foreach, strict keyword, operator
overloading, nested types, records with methods etc...
I do think that .NET swayed too far with some features (like
all elements are objects, all is GC.. etc..) and I see an
oppertunity for Delphi to implement similar capabilities
but without the {*word*193} side effects. (its easier to be smart
after the fact).
Regards!
Atmapuri
 
 

Re: Unmanaged Possibilities

Quote
Everything I have ever done in Pascal was achievable using attributes in
dotnet
Show me how you did a for loop :-)
Quote
and everything I have done so far with attributes would be possible
in Pascal.
Just not as neatly. I think NUnit is an example of attributes well-used. Writing
unit tests in NUnit is much neater than with DUnit, for example.
Not having to inherit from a base test class is a good thing, both from a clean
design POV, and because it lets you use a neater way of testing protected
methods. In DUnit you do this by this sort of code
...
implementation
type
TSubclassONlyFOrTestingPurposes = class(TMyClassToTest)
end;
Then you unit test create objects of this new type so they can get at the
protected stuff.
In NUnit you can inherit the test class from the type to be tested :
...
interface
type
[TestFixture]
TMyClassToTestTests = class(TMyClassToTest)
...
end;
Then all the tests can use protected stuff (you could also have used reflection
for this and private stuff, of course).
Quote
I think that virtual static members just dirtied the design of the class
Do you mean members or methods?
I still like virtual static methods, as I think the design becomes cleaner, and
does away entirely with the need for Singletons, for example.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: Unmanaged Possibilities

Damian Wood writes:
Quote
I've always wondered, what kind of magic did Borland employ to make
designtime/runtime packages work?
Almost none. Packages are DLLs with a few extra features. Most of the
"type discovery" requires static binding, so there's lots of
information available to the compiler via the DCP at that time. You
don't get those features when you dynamically load a BPL at runtime.
Packages don't allow any reflection beyond what RTTI already provides.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: Unmanaged Possibilities

Hi!
Quote
Packages don't allow any reflection beyond what RTTI already provides.
But they could be made to provide it. I see no point in having the
ability to define an attribute to an integer type. But only to classes
and records. Probably you could address 99% of features currently
in .NET by supporting only classes and records.
(And it would be unmanaged, no GC and FAST)
The first use of attributes that comes to my mind is the
ability to specify the description and category for properties
for the object inspector to use at design time.
So there should be run-time and design time attributes.
No need to link in design time attributes in to application
as .NET does now.
Regards!
Atmapuri
 

Re: Unmanaged Possibilities

"Atmapuri" <XXXX@XXXXX.COM>a écrit dans le message de news:
444f7ab7$XXXX@XXXXX.COM...
| But they could be made to provide it. I see no point in having the
| ability to define an attribute to an integer type. But only to classes
| and records. Probably you could address 99% of features currently
| in .NET by supporting only classes and records.
Attributes are rarely used to extend simple types, rather they are used to
extend the metadata available on complex types.
However, I have seen a great deal of overuse of attributes, especially in
certain frameworks where you can end up with so many attributes, you can
find it difficult to find the class definiton !!
| (And it would be unmanaged, no GC and FAST)
You don't really still believe that .NET is *that* slow do you ? (please
don't divert this thread into another argument on that topic)
| The first use of attributes that comes to my mind is the
| ability to specify the description and category for properties
| for the object inspector to use at design time.
This use of attributes is something that pollutes the business layer of an
application and should really only be used for visual components or UI
adapters rather than general business classes.
| So there should be run-time and design time attributes.
| No need to link in design time attributes in to application
| as .NET does now.
There are IDE and designer features that can be used to create converters,
descriptors, etc that avoid having to load up "runtime" classes.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Unmanaged Possibilities

Quote
Do you mean members or methods?
I meant methods, writing "member" to describe methods+attributes+roles is a
habit now :-)
Quote
I still like virtual static methods, as I think the design becomes
cleaner, and does away entirely with the need for Singletons, for example.
I think the design becomes dirtier :-) How do they do away with the need
for singletons?
 

Re: Unmanaged Possibilities

Quote
strict keyword
The change I dislike the most! I'd have preferred it if protected had
meant protected, and anyone who wants it to mean internal had to change
their source.
 

Re: Unmanaged Possibilities

"Peter Morris [Droopy eyes software]" wrote
Quote

The change I dislike the most! I'd have preferred it if protected had
meant protected, and anyone who wants it to mean internal had to change
their source.
I agree that that would be much cleaner, but it would have broken a lot of
existing code.
bobD
 

Re: Unmanaged Possibilities

Quote
The first use of attributes that comes to my mind is the
ability to specify the description and category for properties
for the object inspector to use at design time.
And indeed that is how that is done in .NET
Quote
So there should be run-time and design time attributes.
Yes (if by design time you mean attributes used at design time by the IDE),
although both those tend to be predefined. It is useful to be able to define
your own attributes (almost always for use at runtime, naturally)
Quote
No need to link in design time attributes in to application
as .NET does now.
Why not? Some tools might want to use them (eg documentation tools / language
translation tools like Reflector). it is not a great overhead.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: Unmanaged Possibilities

Quote
This use of attributes is something that pollutes the business layer of an
application and should really only be used for visual components or UI
adapters rather than general business classes.
Oh, I don't entirely agree with that. It can be quite useful in business classes
as well.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: Unmanaged Possibilities

Quote
I think the design becomes dirtier :-)
Why?
Quote
How do they do away with the need for singletons?
If you have static fields/properties, and virtual static methods (and maybe
virtual constructors), you no longer need to enforce only one instance, as you
can use static everythings.
In Delphi Win32 you need the Singleton pattern because you don't have static
properties, in C++ you need the Singleton pattern because you cannot inherit
from a class with all static methods (at least, not if you want to override any
of the methods).
In Delphi for .NET you do not need the Singleton pattern because you can have
static everythings, and also override static methods and constructors.
You only need the pattern if you want>1, but still limited numbers of
instances (which is an extension of the Singleton pattern)
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: Unmanaged Possibilities

"Jim Cooper" <XXXX@XXXXX.COM>a écrit dans le message de news:
444f93e0$XXXX@XXXXX.COM...
|>This use of attributes is something that pollutes the business layer of
an
|>application and should really only be used for visual components or UI
|>adapters rather than general business classes.
|
| Oh, I don't entirely agree with that. It can be quite useful in business
classes
| as well.
I would agree with you there Jim. Maybe I should have said "the use of
attributes relevant to UI behaviour" :-)
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Unmanaged Possibilities

Barry Kelly writes:
Quote
"Joanna Carter [TeamB]" <XXXX@XXXXX.COM>writes:

>"Herbert Sitz" <XXXX@XXXXX.COM>a écrit dans le message de news:
>XXXX@XXXXX.COM...
>
>>The support for
>>generics is compile time support (as in c++) and not runtime
>>support (as .net has).
>
>Huh?? .NET generics are bound at compile time, they are even
>strongly typed in the Code Insight hints.

.NET generics certainly are typechecked at compile time, but the
actual runtime types are instantiated at runtime. What's more unique
is that you can instantiate generic types yourself using reflection.
Not completely true. If you're using generics with structs, .net
generates a new class at compile time.
--
Mike Swaim XXXX@XXXXX.COM at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
XXXX@XXXXX.COM or XXXX@XXXXX.COM at work
ICBM: 29.763N 95.363W|Disclaimer: Yeah, like I speak for MD Anderson.
 

Re: Unmanaged Possibilities

Rick Carter writes:
Quote
>blogs.borland.com/dcc/archive/2004/03/26/2379.aspx
>
>In the end, the decision was that attributes on Win32 didn't make sense
>in the absence of a .NET-like ecosystem to support them.

Well, in the article, it sounds like Danny wasn't convinced whether it
would be worthwhile or not, and he was asking people to help him decide.
Assuming there were replies, I can not see any of them from the link
provided. It would be interesting to see the discussion that followed.
Indeed it does and I was more or less following up with what the
conclusion was. IIRC Danny discussed this conclusion in the comments to
this blog entry which unforutnately are no longer available as all
comments to that blog have been turned off (a real bummer).
--
-Steve
Delphi.NET/C#Builder R&D
Borland Software Corporation
homepages.borland.com/strefethen
blogs.borland.com/stevet
 

Re: Unmanaged Possibilities

"Mike Swaim" <XXXX@XXXXX.COM>writes:
Quote
>.NET generics certainly are typechecked at compile time, but the
>actual runtime types are instantiated at runtime. What's more unique
>is that you can instantiate generic types yourself using reflection.

Not completely true. If you're using generics with structs, .net
generates a new class at compile time.
C# does all the necessary work to type-check generics at compile time, but
it does not generate generic type instantiations at compile-type for
either classes or structs.
There does exist a valuable distinction however:
A major difference between struct and classes with respect to generics is
that when a generic type (doesn't matter whether a struct or class) is
instantiated with a reference type, the CLR uses System.__Canon (an
internal class in mscorlib) to fold all the generated generic
instantiations into one single instantiation.
When a generic type is instantiated with a value type, the CLR can not play
the same trick. Thus generic types instantiated with value type arguments
are more costly than generic types instantiated with reference type
arguments.
---8<---
using System;
struct S<T>
{
public T value;
}
class App
{
static void Main()
{
S<int>x = new S<int>();
x.value = 3;
S<string>y = new S<string>();
y.value = "4";
}
}
--->8---
Disassembled with ildasm piped through grep '.class':
---8<---
.class /*02000002*/ private sequential ansi sealed beforefieldinit S`1<T>
} // end of class S`1
.class /*02000003*/ private auto ansi beforefieldinit App
} // end of class App
--->8---
The type instantiation is just like JIT compilation. The instantiated
types don't exist in the compiled assembly (.exe or .dll) at all. The
types are instantiated by the CLR, in memory, at runtime, when a reference
in the IL or via reflection comes along which requires the type. At that
time, the type gets constructed. Any further references to the same
instantiation will use the existing instantiation. This is with pre-JIT
excluded, naturally (I have no idea what it does in that case).
This approach is related to the reason why folks complain that Delphi is
less snappy than it was. .NET applications do as little work as possible
up front (because frameworks are large, require a lot of IO to load, and
touch a lot of pages etc.). A consequence of this is that using a
particular area of a freshly started .NET application for the first time
often incurs a hit, an element of the delayed startup cost.
-- Barry