D - D / tutorial / stdlib / killer app
- Helmut Leitner (53/53) Jul 30 2003 A few general thoughts about the current situation.
- Frank Wills (40/97) Jul 30 2003 Helmut,
- Helmut Leitner (5/18) Jul 31 2003 I completely agree.
- Riccardo De Agostini (33/69) Jul 30 2003 200% right IMHO.
- J. Daniel Smith (21/74) Jul 30 2003 I think one of the reasons for C++'s popularity is that was easy to get
- Riccardo De Agostini (26/37) Jul 31 2003 You're right, but I think times have changed enough. When C++ was born, ...
- Matthew Wilson (11/14) Jul 31 2003 It never ceases to amaze me that people think C++ is an object-oriented
- Riccardo De Agostini (13/22) Jul 31 2003 I apologize for the imprecision.
- Matthew Wilson (24/31) Jul 31 2003 Am intrigued by what you mean here. Do you mean one or the other?
- Riccardo De Agostini (23/24) Jul 31 2003 The point here was not having *two* I/O libraries. My personal preferenc...
- Matthew Wilson (15/38) Jul 31 2003 Cool. ;)
- Riccardo De Agostini (26/31) Jul 31 2003 With as many reasons as there are good, off-the-shelf (or off-the-CVS)
- J. Daniel Smith (30/67) Jul 31 2003 The reason a C++ programmer won't switch to D is that in the real world
- Walter (3/3) Jul 30 2003 You have some great points.
- Walter (17/48) Jul 30 2003 Right up to a point. Notice that C++, Python, Java, Eiffel, C#, etc., et...
- Riccardo De Agostini (17/23) Jul 31 2003 overloading,
- Matthew Wilson (33/37) Jul 31 2003 That's utter nonsense. On what do you base this?
- Riccardo De Agostini (29/33) Jul 31 2003 hardly
- Matthew Wilson (40/74) Jul 31 2003 Indeed.
- Walter (22/45) Aug 07 2003 expressiveness
- Mike Wynn (18/21) Aug 07 2003 of
- Matthew Wilson (35/80) Aug 07 2003 criticisms
- Walter (3/6) Aug 10 2003 Yes, I'm up for working on the syntax of D templates to make a DTL work.
- Bill Cox (51/56) Jul 31 2003 Hi.
- Riccardo De Agostini (6/8) Jul 31 2003 ROTFL!
- Bill Cox (6/21) Aug 01 2003 No, I wasn't serious. I think the recent posts on this group are
- Walter (5/8) Aug 07 2003 LOL. Did you know that I won that contest years back? I can write horrib...
- Matthew Wilson (74/74) Jul 30 2003 Maybe we're trying to byte off more than we can chew.
- Riccardo De Agostini (21/64) Jul 31 2003 going
- Burton Radons (18/47) Aug 03 2003 IMO Phobos should be cannibalised. The purpose of having a default
- Les Baker (4/6) Aug 03 2003 FYI on a potential name collision too -- "SDL" is the acronym for Simple
- Matthew Wilson (11/17) Aug 03 2003 This is all kind of missing the point. If I gave the impression that I
- Charles Sanders (14/40) Aug 03 2003 Definetly! I think this is very important, and I think we should stop j...
- Riccardo De Agostini (15/19) Aug 04 2003 Absolutely. Some people are already developing D libraries, naming them
- Helmut Leitner (6/16) Aug 04 2003 Arrgh. "import files" will collide with any Sourcefile "files.d" that
- Riccardo De Agostini (8/10) Aug 04 2003 As a matter of fact, I was not. :-) Just making an example. A rather bad
- Helmut Leitner (10/21) Aug 04 2003 I think there have been a number of discussions about this.
- Walter (3/9) Aug 16 2003 I'm sick of acronyms, too.
- Andrew Marlow (6/16) Aug 17 2003 It also stands for System Design Language,a design notation still used i...
- Riccardo De Agostini (8/21) Aug 04 2003 Munch, munch, crunch, crunch... :-)
- Frank Wills (7/10) Aug 04 2003 I agree with this. I also think the libraries should be modular,
- Walter (32/32) Aug 16 2003 I want to encourage everyone to help out with the library. My primary fo...
- Charles Sanders (17/49) Aug 16 2003 Great I was wondering about this, I remember alot of activity but don't
- Mike Wynn (822/829) Aug 16 2003 ?
- Sean L. Palmer (54/54) Aug 17 2003 charset="iso-8859-1"
- Peter Hercek (4/66) Aug 16 2003 You may try this instead of CVS: http://subversion.tigris.org/
- Friedrich Dominicus (27/67) Aug 18 2003 Well if you build a library based on objects you will have branches of
- Helmut Leitner (16/60) Aug 26 2003 If I try to boil this down, I arrive at:
A few general thoughts about the current situation.
Walter and Burton do an admirable job to push D forward. But to help
them we (all others) have to find ways to contribute code and collaborate
more effectively.
To use D it's nice to have this tight C connection, but in the long
run it will be an hindrance to make C popular. You can't write a nice
and easy tutorial if you have to fall back to printf or scanf. So there
should a line of thought that targets the non-C-D-beginner. In the end
there must be something like (pseudocode):
Print("Enter Date: ");
Input(date);
Push(DataArray,date);
Print("Today: ",date);
Only easy things become popular.
The same is true for the stdlib. D needs the gui (dig), ide, print,
image, scan, cgi, database and a miriad of other modules. But it won't
help much if this functionality is distributed among many libraries
and written in many different styles. We should find a way to establish
a D library style, that's powerful and unbloated. It doesn't make sense
(I specially remember the Java class to read numbered lines from a stream)
We don't have Sun or Microsoft resources to go this "brute force" way.
(And I don't think its programmer-friendly anyway)
It seems that D would lend itself well to a mixed OO style, where only
the core functionality is OO, while other functions explicitely pass
the main object and can be stripped by the linker (avoiding bloat).
For example, if you do user interfaces and report generations you handle
all types of rectangular areas (frames) and dependencies. I think my
C RECT module contains about 80 functions to split, join, change and
position rectangles. It doesn't make sense to add functions to libraries
(to classes) when they increase the footprint of applications using the
libraries. D has a way around this, but no established style to make
good use of it. This hasn't been discussed.
Even the current Phobos library seems already a rather inconsistent
mix of styles. I also think that the duplication of C functions in
D libraries is a bad habit. We don't live under the 6/8 char name
restriction anymore and should use readable names consistently.
A way to do this would be introduce a common vocabulary of names
with a defined meaning, so that a user/programmer can rely upon
that any image function will have "Image" (and not "Picture",
"Pict" or "Img") in its name. A while ago I did quite an amount
of work about this type of consistent vocabularies. Typically its hard
to get people to give up their "freedom" to name functions the way
they like - but its the only way to get consistency into large APIs.
The production of good apps (killer apps) will also work better when the
developments can be coordinated to build the apps and the core library
at the same time, avoiding redundant development work. This would need
a repository where developers can directly contribute without creating
unstable systems. This would need some kind of automated build and test
system. But I've no idea how this could be accomplished.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com
Jul 30 2003
Helmut,
I think that in essence you are right.
- If we want to see D be truely successful in
the mainstream we need to create a development
environment that covers all of the bases.
- We want to do this in a standardized way,
perhaps creating a 'D' way of doing things that
extends and fulfills the philosophy of the D
language. This we can't do successfully if we
contribute in a disjointed manner. I agree
with that.
- To do this we certainly need to work together
to define this D development environment, standard,
and philosophy. From there we can define the
tool and environment components, gui library, ide,
image, scan, cgi, database, and etcetera.
- Personally, D is what I have been looking
forward to seeing someone develop, Walter has
done a lot by giving us this, and I think it
would certainly be worth the effort to pitch
in as a team to achieve these goals.
- As a thought, we need a website that can
project what we formalize, decide, discuss,
and accomplish as we go (assuming we reach
a concensus along these lines and work towards
something like this.)
- As a final thought, all of this would require
a lot of work for some time. What persuades me
is that after years of watching and waiting to
see what would follow C and C++, the solutions
that the major companies have come up with
fall short of what I had hoped for, and deviate
to some extent as well, such as with the use
of VMs and massive resource requirements. So,
given that these companies are not heading
in the direction that we really want, I
think it may truely be worthwhile to make
the committment to work together towards
such a goal.
Helmut Leitner wrote:
A few general thoughts about the current situation.
Walter and Burton do an admirable job to push D forward. But to help
them we (all others) have to find ways to contribute code and collaborate
more effectively.
To use D it's nice to have this tight C connection, but in the long
run it will be an hindrance to make C popular. You can't write a nice
and easy tutorial if you have to fall back to printf or scanf. So there
should a line of thought that targets the non-C-D-beginner. In the end
there must be something like (pseudocode):
Print("Enter Date: ");
Input(date);
Push(DataArray,date);
Print("Today: ",date);
Only easy things become popular.
The same is true for the stdlib. D needs the gui (dig), ide, print,
image, scan, cgi, database and a miriad of other modules. But it won't
help much if this functionality is distributed among many libraries
and written in many different styles. We should find a way to establish
a D library style, that's powerful and unbloated. It doesn't make sense
(I specially remember the Java class to read numbered lines from a stream)
We don't have Sun or Microsoft resources to go this "brute force" way.
(And I don't think its programmer-friendly anyway)
It seems that D would lend itself well to a mixed OO style, where only
the core functionality is OO, while other functions explicitely pass
the main object and can be stripped by the linker (avoiding bloat).
For example, if you do user interfaces and report generations you handle
all types of rectangular areas (frames) and dependencies. I think my
C RECT module contains about 80 functions to split, join, change and
position rectangles. It doesn't make sense to add functions to libraries
(to classes) when they increase the footprint of applications using the
libraries. D has a way around this, but no established style to make
good use of it. This hasn't been discussed.
Even the current Phobos library seems already a rather inconsistent
mix of styles. I also think that the duplication of C functions in
D libraries is a bad habit. We don't live under the 6/8 char name
restriction anymore and should use readable names consistently.
A way to do this would be introduce a common vocabulary of names
with a defined meaning, so that a user/programmer can rely upon
that any image function will have "Image" (and not "Picture",
"Pict" or "Img") in its name. A while ago I did quite an amount
of work about this type of consistent vocabularies. Typically its hard
to get people to give up their "freedom" to name functions the way
they like - but its the only way to get consistency into large APIs.
The production of good apps (killer apps) will also work better when the
developments can be coordinated to build the apps and the core library
at the same time, avoiding redundant development work. This would need
a repository where developers can directly contribute without creating
unstable systems. This would need some kind of automated build and test
system. But I've no idea how this could be accomplished.
Jul 30 2003
Helmut Leitner <helmut.leitner chello.at> Frank Wills wrote:- As a final thought, all of this would require a lot of work for some time. What persuades me is that after years of watching and waiting to see what would follow C and C++, the solutions that the major companies have come up with fall short of what I had hoped for, and deviate to some extent as well, such as with the use of VMs and massive resource requirements. So, given that these companies are not heading in the direction that we really want, I think it may truely be worthwhile to make the committment to work together towards such a goal.I completely agree. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Jul 31 2003
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio news:3F279BAE.41C709AD hls.via.at...A few general thoughts about the current situation. [...] To use D it's nice to have this tight C connection, but in the long run it will be an hindrance to make C popular. You can't write a nice and easy tutorial if you have to fall back to printf or scanf. So there should a line of thought that targets the non-C-D-beginner.200% right IMHO.The same is true for the stdlib. D needs the gui (dig), ide, print, image, scan, cgi, database and a miriad of other modules. But it won't help much if this functionality is distributed among many libraries and written in many different styles. We should find a way to establish a D library style, that's powerful and unbloated. It doesn't make senseI don't agree completely: while a D library style is surely one of the most important (and urgent) things to consider, I wouldn't spend time and energy on GUI, print, etc. etc. until we have that style in a more-than-just-draft form. As developing libraries of some kind is important in order to refine the library style specs, why not concentrate on replacing stdio and other C heritage, for now? (Mind that "now" could mean a short time if enough people take it seriously).It seems that D would lend itself well to a mixed OO style, where only the core functionality is OO, while other functions explicitely pass the main object and can be stripped by the linker (avoiding bloat).I don't see what you mean by passing the main object...[...] It doesn't make sense to add functions to libraries (to classes) when they increase the footprint of applications using the libraries. D has a way around this, but no established style to make good use of it. This hasn't been discussed.Either I am not understanding (which is most probable) or that sounds like the need for a smart linker (à la Borland), which does not include functions in the executable if they are not called at all.Even the current Phobos library seems already a rather inconsistent mix of styles. I also think that the duplication of C functions in D libraries is a bad habit. We don't live under the 6/8 char name restriction anymore and should use readable names consistently.Right said! Since D assumes at least a 32-bit flat memory space and Unicode support, why sticking with function declarations written in 1979, even if stdio.h was a blessing at the time?A way to do this would be introduce a common vocabulary of names with a defined meaning, so that a user/programmer can rely upon that any image function will have "Image" (and not "Picture", "Pict" or "Img") in its name. A while ago I did quite an amount of work about this type of consistent vocabularies. Typically its hard to get people to give up their "freedom" to name functions the way they like - but its the only way to get consistency into large APIs.This sounds a little risky, but after all, that's what Sun did with Java, and M$ with .NET, just brought at a slightly higher level. And D *is* about bringing things at the next level, isn't it?The production of good apps (killer apps) will also work better when the developments can be coordinated to build the apps and the core library at the same time, avoiding redundant development work. This would need a repository where developers can directly contribute without creating unstable systems. This would need some kind of automated build and test system. But I've no idea how this could be accomplished.I guess there's no way, for free at least... But having Phobos on a CVS (say on Sourceforge for instance) could be a good start, as long as Walter agrees. And while I'm on the subject: Phobos is a cool codename for the library, but maybe something like SDL (for "Standard D library") or the like, although all but original, could sound more convincing to people considering D for professional use. Needless to say, either Walter himself or someone who can be trusted to follow his guidelines must be in charge of CVS maintenance. As for myself, I'm willing to contribute, so expect to read more from me soon... Bye Ric
Jul 30 2003
I think one of the reasons for C++'s popularity is that was easy to get
there from C. The first step was to just compile all of your existing C
code with the C++ compiler, almost everything worked as-is and the needed
changes were minimal. With just a little bit of effort, you could write
code that could be compiled with both the C and C++ compilers (this is still
somewhat true today, although things like the STL and C99 complicate
things).
time/effort/$$$ to birth a new language with everything that is required for
modern development (IDE, libraries, etc.). D is probably always going to
have a hard time keeping up with the likes of Sun and Microsoft.
Something that might work with D - although it would require somewhat
substantial changes at this point - is to make D compatible with a "nice"
subset of C++. This would allow D to easily leverage much of what is
available for C++; D-specific code could be inside of #ifdef's so that they
are only visible to the D compiler.
think that by itself is enough to really make D popular.
Dan
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F279BAE.41C709AD hls.via.at...
A few general thoughts about the current situation.
Walter and Burton do an admirable job to push D forward. But to help
them we (all others) have to find ways to contribute code and collaborate
more effectively.
To use D it's nice to have this tight C connection, but in the long
run it will be an hindrance to make C popular. You can't write a nice
and easy tutorial if you have to fall back to printf or scanf. So there
should a line of thought that targets the non-C-D-beginner. In the end
there must be something like (pseudocode):
Print("Enter Date: ");
Input(date);
Push(DataArray,date);
Print("Today: ",date);
Only easy things become popular.
The same is true for the stdlib. D needs the gui (dig), ide, print,
image, scan, cgi, database and a miriad of other modules. But it won't
help much if this functionality is distributed among many libraries
and written in many different styles. We should find a way to establish
a D library style, that's powerful and unbloated. It doesn't make sense
(I specially remember the Java class to read numbered lines from a stream)
We don't have Sun or Microsoft resources to go this "brute force" way.
(And I don't think its programmer-friendly anyway)
It seems that D would lend itself well to a mixed OO style, where only
the core functionality is OO, while other functions explicitely pass
the main object and can be stripped by the linker (avoiding bloat).
For example, if you do user interfaces and report generations you handle
all types of rectangular areas (frames) and dependencies. I think my
C RECT module contains about 80 functions to split, join, change and
position rectangles. It doesn't make sense to add functions to libraries
(to classes) when they increase the footprint of applications using the
libraries. D has a way around this, but no established style to make
good use of it. This hasn't been discussed.
Even the current Phobos library seems already a rather inconsistent
mix of styles. I also think that the duplication of C functions in
D libraries is a bad habit. We don't live under the 6/8 char name
restriction anymore and should use readable names consistently.
A way to do this would be introduce a common vocabulary of names
with a defined meaning, so that a user/programmer can rely upon
that any image function will have "Image" (and not "Picture",
"Pict" or "Img") in its name. A while ago I did quite an amount
of work about this type of consistent vocabularies. Typically its hard
to get people to give up their "freedom" to name functions the way
they like - but its the only way to get consistency into large APIs.
The production of good apps (killer apps) will also work better when the
developments can be coordinated to build the apps and the core library
at the same time, avoiding redundant development work. This would need
a repository where developers can directly contribute without creating
unstable systems. This would need some kind of automated build and test
system. But I've no idea how this could be accomplished.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com
Jul 30 2003
"J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> ha scritto nel messaggio news:bg8pk6$1ina$1 digitaldaemon.com...I think one of the reasons for C++'s popularity is that was easy to get there from C. The first step was to just compile all of your existing C code with the C++ compiler, almost everything worked as-is and the needed changes were minimal.You're right, but I think times have changed enough. When C++ was born, OOP (C++'s main advantage over C) was far less popular than today; programmers had to gradually get used to C++ because it required them (us) to do things in a way they were not used to and, at first sight, required more typing and more complicated code (until people got used to OO *analysis*, that is). D, on the other hand, does not introduce dramatically new programming concepts and requires the programmer to type *less*. As long as the language does not get cluttered by strange symbols (see the discussion about string literals), I can't see a reason why a C++ programmer wouldn't want to switch to D, at least not a single reason regarding the language itself: the fact that perhaps I'll have to fight with my boss to use a non-M$ language, although bearing a practical importance, is not pertinent here.Something that might work with D - although it would require somewhat substantial changes at this point - is to make D compatible with a "nice" subset of C++. This would allow D to easily leverage much of what is available for C++; D-specific code could be inside of #ifdef's so thattheyare only visible to the D compiler.Please, no! :-) Reintroducing the preprocessor would mean reintroducing macros. I like C-style macros, but only when I code in C, because they can help me write better and more understandable code, and even if they can make me write spaghetti code just as easily, in C there are no serious alternatives at times. Delphi, whose OO features resemble D in many ways, does not have a preprocessor, nor did I ever feel a need for it, except in one case where, thinking better, what I really needed was not a preprocessor, but templates (which D has). My personal vote goes against the preprocessor.think that by itself is enough to really make D popular.I agree: it needs the best standard library ever seen. So let's make it! :-) Ric
Jul 31 2003
You're right, but I think times have changed enough. When C++ was born,OOP(C++'s main advantage over C)It never ceases to amaze me that people think C++ is an object-oriented language. It is not. It is a language that supports object-oriented programming (whatever that means) if that's what you choose to code. C++'s biggest advantage(s) over C are RAII and templates. Inheritance, and all the other OO gunk, is just a nice extra.I agree: it needs the best standard library ever seen. So let's make it!:-) Agreed with this. However, as I said in another thread, it needs to be orthogonal, efficient (in size and speed), and well thought-out/tested. Oh, and it needs to support equally those who program in "a better C", or who like OOP, or who like generics.
Jul 31 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgaguk$9ta$1 digitaldaemon.com...It never ceases to amaze me that people think C++ is an object-oriented language. It is not. It is a language that supports object-oriented programming (whatever that means) if that's what you choose to code.I apologize for the imprecision.C++'s biggest advantage(s) over C are RAII and templates. Inheritance, and all the other OO gunk, is just a nice extra.IIRC, commercial C++ compilers were advertised, from the beginning, as if they held the key to programmer's heaven, and that key was OOP, at least according to marketing people. As to templates, C++ had been out for quite a while when they were introduced. So I agree with you, but they weren't part of the initial "big promise".Agreed with this. However, as I said in another thread, it needs to be orthogonal, efficient (in size and speed), and well thought-out/tested.Oh,and it needs to support equally those who program in "a better C", or who like OOP, or who like generics.That would be great. Having both stdio and iostreams would not. Just my opinion, anyway. Ric
Jul 31 2003
whoAgreed with this. However, as I said in another thread, it needs to be orthogonal, efficient (in size and speed), and well thought-out/tested.Oh,and it needs to support equally those who program in "a better C", orAm intrigued by what you mean here. Do you mean one or the other? For my part, I think the iostreams stink, but not because they attempt to provide a type-sensitive approach to streaming, rather just because it's done really badly. I would think we should support both stdio (probably just leave it as the C-interface, though that's not to say that people will not come up with worthy enhancements that do not take it away from the "raw" C model), and also a decent DStreams (have I just invented a new name?), that does all the things that the iostreams should have done well, and a lot more besides, while being small and quick. (Needless to say, the iostreams SUCK HARD when it comes to speed.) The DStreams would be a combination of template and non-template components that would provide a near maximal blend of speed, type-safety and ease-of-use, not to mention a decent exceptional model, and handling byte-order as a matter of course. If I was lucky enough to get voted onto the DLG panel, I would take a very keen interest in assisting with this very subject. (And if no-one starts any serious work on it within the next 2-3 months - by which time I may be free of book writing duties for a while - I will probably have a go at it myself. Time, as always, being the limiting factor. Russ Lewis and Jon Allen had a brief chat about this in March, but I've not heard anyone mention it since.) Matthew P.S. Ricardo, can you leave a blank line before your answers, when they're embedded, as it makes them hard to spot? :)like OOP, or who like generics.That would be great. Having both stdio and iostreams would not. Just my opinion, anyway.
Jul 31 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgajqq$cd6$1 digitaldaemon.com...Am intrigued by what you mean here. Do you mean one or the other?The point here was not having *two* I/O libraries. My personal preference goes to neither one: I find stdio to be nearly Louis XVI style and agree with every word you say about iostreams. I agree completely with your vision about the library, just I don't see the need for keeping stdio. I'd add that it is important to keep simple things simple: even Java's system.out.println looks too verbose in a "Hello world" example IMHO, fancy when you have to write hundreds of such calls in an app. I'd suggest stdin and stdout (maybe StdIn, StdOut and of course StdErr, or better DebugOut) as names for global classes, since StdOut.Write(<whatever>) looks "procedural" enough as to not scare C programmers so much as cout << <what> << <ever> can do. As to the DStreams name: looks sexy, but just Streams is perhaps more "natural". Since streams are to be part of D's standard library (at least that's what I infer from discussions on the NG) that would mean Dstreams, DContainers, DLists, DSockets, etc. for consistency. Now try to figure if everything in the STL was prefixed CPP... I'd also avoid DIO as a name for the I/O library, since it means "God" in Italian, so it makes for weird word tricks in sources. Being concerned about Microsoft and Sun makes sense, but when you add the Vatican it becomes overwhelming! :-) Ric
Jul 31 2003
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message news:bgamt3$f11$1 digitaldaemon.com..."Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgajqq$cd6$1 digitaldaemon.com...Cool. ;)Am intrigued by what you mean here. Do you mean one or the other?The point here was not having *two* I/O libraries. My personal preference goes to neither one: I find stdio to be nearly Louis XVI style and agree with every word you say about iostreams.I agree completely with your vision about the library, just I don't seetheneed for keeping stdio. I'd add that it is important to keep simple things simple: even Java's system.out.println looks too verbose in a "Helloworld"example IMHO, fancy when you have to write hundreds of such calls in anapp.I'd suggest stdin and stdout (maybe StdIn, StdOut and of course StdErr, or better DebugOut) as names for global classes, sinceStdOut.Write(<whatever>)looks "procedural" enough as to not scare C programmers so much as cout << <what> << <ever> can do.Makes sense. I just don't see us jettisoning stdio. That's not to say it will be promoted as the best way to do things, but really it cannot be removed, since we're always going to have the facility for calling C functions (with good reason).As to the DStreams name: looks sexy, but just Streams is perhaps more "natural". Since streams are to be part of D's standard library (at least that's what I infer from discussions on the NG) that would mean Dstreams, DContainers, DLists, DSockets, etc. for consistency. Now try to figure if everything in the STL was prefixed CPP...I just thought it up on the spot. There'd be no reason to want to use that actual name in the code. It was more a working title.I'd also avoid DIO as a name for the I/O library, since it means "God" in Italian, so it makes for weird word tricks in sources. Being concernedaboutMicrosoft and Sun makes sense, but when you add the Vatican it becomes overwhelming! :-)3 gods! Too many to contemplate. And only two of them real ...
Jul 31 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgao81$g3e$1 digitaldaemon.com...Makes sense. I just don't see us jettisoning stdio. That's not to say it will be promoted as the best way to do things, but really it cannot be removed, since we're always going to have the facility for calling C functions (with good reason).With as many reasons as there are good, off-the-shelf (or off-the-CVS) third-party libraries with a C interface. If you tell me that D lets me use a $200 C library I bought six months ago and use every day, that's great! What? It also interfaces with third-party DLLs? A blessing! Can I also use WATT-32 (if just DMD compiled for DOS-32 too...)? Cool as dry ice!! Then you add "...and it has fopen and printf...". So what?! :-) It won't compile my C code as-is anyway (nor do I want it to do it) so let me see if it comes with something smarter than stdio... I understand that throwing the C RTL out of the D window completely is not very practical... I see two appealing possibilities: 1) Keeping the interface modules to the C RTL, but not as part of the core library, so as to make it clear that D can do the same things in a "native" way and, needless to say, better :-) 2) Create "interface" modules (not part of the core library, either) which implement, for instance, stdio functions with calls to the Streams library. More work involved, of course, but this would let us eliminate the use of pointers (especially char *) in library calls because, for instance, strrchr could take a char[] as parameter. Besides, the compiler would very probably make most of the calls inline, thus eliminating the overhead. With special regard to stdio, I confess that the idea of potentially having a Streams library *and* stdio linked together in the same app makes me feel uncomfortable.3 gods! Too many to contemplate. And only two of them real ...Only one. M$ is the devil. ;-) Ric
Jul 31 2003
The reason a C++ programmer won't switch to D is that in the real world there is far too much "legacy" C++ code that you have to work with or leverage. Most people won't have the luxury of doing *everything* in D, and providing D versions of IDEs, libraries, etc. is going to take a LONG time. Having its roots in "systems programming", D's interface to legacy code is through C, not C++: a C++ class can not be used directly (code compatible) or indirectly (link compatible) by D. I wasn't thinking of adding the whole C pre-processor to D, rather something let you #ifdef code. The idea being that you could write this D dialect of C++ to use with your C++ compiler, while #ifdef'ing out the D-specific things that only the D compiler recognizes. in D is a herculean effort; thus my thoughts about changing D so that is could easily leverage much of C++ similar to C++ using C. Dan "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message news:bgaffd$8jt$1 digitaldaemon.com..."J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> ha scritto nel messaggio news:bg8pk6$1ina$1 digitaldaemon.com...neededI think one of the reasons for C++'s popularity is that was easy to get there from C. The first step was to just compile all of your existing C code with the C++ compiler, almost everything worked as-is and theOOPchanges were minimal.You're right, but I think times have changed enough. When C++ was born,(C++'s main advantage over C) was far less popular than today; programmers had to gradually get used to C++ because it required them (us) to dothingsin a way they were not used to and, at first sight, required more typingandmore complicated code (until people got used to OO *analysis*, that is).D,on the other hand, does not introduce dramatically new programmingconceptsand requires the programmer to type *less*. As long as the language doesnotget cluttered by strange symbols (see the discussion about stringliterals),I can't see a reason why a C++ programmer wouldn't want to switch to D, at least not a single reason regarding the language itself: the fact that perhaps I'll have to fight with my boss to use a non-M$ language, although bearing a practical importance, is not pertinent here."nice"Something that might work with D - although it would require somewhat substantial changes at this point - is to make D compatible with amakesubset of C++. This would allow D to easily leverage much of what is available for C++; D-specific code could be inside of #ifdef's so thattheyare only visible to the D compiler.Please, no! :-) Reintroducing the preprocessor would mean reintroducing macros. I like C-style macros, but only when I code in C, because they can help me write better and more understandable code, and even if they canme write spaghetti code just as easily, in C there are no serious alternatives at times. Delphi, whose OO features resemble D in many ways, does not have a preprocessor, nor did I ever feel a need for it, except in one case where, thinking better, what I really needed was not a preprocessor, but templates (which D has). My personal vote goes against the preprocessor.don't:-)think that by itself is enough to really make D popular.I agree: it needs the best standard library ever seen. So let's make it!Ric
Jul 31 2003
You have some great points. What we should do is look at other successful grass-roots language system, like Perl and Python, and emulate what works for a collaborative system.
Jul 30 2003
"Helmut Leitner" <leitner hls.via.at> wrote in message news:3F279BAE.41C709AD hls.via.at...To use D it's nice to have this tight C connection, but in the long run it will be an hindrance to make C popular. You can't write a nice and easy tutorial if you have to fall back to printf or scanf. So there should a line of thought that targets the non-C-D-beginner. In the end there must be something like (pseudocode): Print("Enter Date: "); Input(date); Push(DataArray,date); Print("Today: ",date); Only easy things become popular.etc., all have some level of C compatibility. D has a tighter connection than all but C++, even if the only reason is that the operating system API calls are designed to work directly with C. D must have a tight C connection to succeed, so it can link with existing C code.The same is true for the stdlib. D needs the gui (dig), ide, print, image, scan, cgi, database and a miriad of other modules. But it won't help much if this functionality is distributed among many libraries and written in many different styles. We should find a way to establish a D library style, that's powerful and unbloated. It doesn't make sense (I specially remember the Java class to read numbered lines from a stream) We don't have Sun or Microsoft resources to go this "brute force" way. (And I don't think its programmer-friendly anyway)I've started on a D style guide in the documentation, comments are welcome.Even the current Phobos library seems already a rather inconsistent mix of styles.That's my fault. Some bits were contributed by others, and some bits are me casting around for what feels right.I also think that the duplication of C functions in D libraries is a bad habit. We don't live under the 6/8 char name restriction anymore and should use readable names consistently.I partially disagree, for the reason that many C functions are so second nature. Yet many need to be re-engineered to take advantage of overloading, and to switch to the exception model of error handling rather than errno. Each needs to be evaluated on a case by case basis. I eventually want to duplicate enough of the C RTL's functionality that one will not need to link to the C RTL for most purposes.A way to do this would be introduce a common vocabulary of names with a defined meaning, so that a user/programmer can rely upon that any image function will have "Image" (and not "Picture", "Pict" or "Img") in its name. A while ago I did quite an amount of work about this type of consistent vocabularies. Typically its hard to get people to give up their "freedom" to name functions the way they like - but its the only way to get consistency into large APIs.I agree.
Jul 30 2003
"Walter" <walter digitalmars.com> ha scritto nel messaggio news:bg965n$20lp$1 digitaldaemon.com...I partially disagree, for the reason that many C functions are so second nature. Yet many need to be re-engineered to take advantage ofoverloading,and to switch to the exception model of error handling rather than errno. Each needs to be evaluated on a case by case basis. I eventually want to duplicate enough of the C RTL's functionality that one will not need tolinkto the C RTL for most purposes.Why not dropping the C RTL *at all*? It would look more like a serious approach at creating a standard library for D, IMHO... Besides, I don't regard things like fputs, putc, fscputksfv :-) as "practical" programming. Most C programmers I've seen have a tendency to be influenced by the RTL style, yielding things like (as saw by me in production code!) three global variables named RtlSrvMnb, RtlMnbSrv and SrvRtlMnb, and, in general, identifiers seemingly generated by a kitten playing on a keyboard. As for second nature, one who has been coding in C since 1980 will hardly switch... OTOH, there are lots of newbies out there, and they are the future. Let's give them (and us) a really practical RTL. I think D deserves it. Ric
Jul 31 2003
As for second nature, one who has been coding in C since 1980 will hardly switch...That's utter nonsense. On what do you base this? There are old farts who refuse to learn anything newer than the crufty old stuff they learned in university in the 1960s,. and there are ignorant young fools who refuse to learn anything newer or older than that Java/VB they learned in university in the late 1990s. The defining characteristics of these types of people is that they are crap, nothing to do with their age. Furthermore, I haven't spotted any people from this "type" on the D newsgroup, which seems to attract those who are both skilled and open-minded.OTOH, there are lots of newbies out there, and they are the future.They'll only be the future if they learn from people with more experience! As someone who is (in age at least - 35) halfway between the two groups you talk about, I find it incredible to think of your characterisation of either camp. As I get older and more experienced, I learn that I know less than I think I do (something which newbies fail to do to a man) and also become better able to learn new languages and to appreciate the old ones in different ways. So basically I think your two characterisations are wrong and/or fatuous. What we need to do with D is achieve: - efficient execution - efficient coding - and this includes the major component of software engineering (which is never mentioned on this ng!!): maintainance. - lends itself to good design - be grounded in reality. This means being C compatible. - and lot's more besides. Walter is trying to create a language that will be better than C++ (and Java, .NET, etc. etc.). Since all those existing successful languages have got more flaws than you can shake a stick at, perhaps there is some deeper meaning on the likelihood of success based on pragmatism vs idealism. Someone with better memory than I posted something really interesting on how imperfect languages win out over perfect ones every time. If they can be so good as to do so again, I think we should all (re-)read and digest. I recall it was very compelling Matthew
Jul 31 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgahju$adu$1 digitaldaemon.com...hardlyAs for second nature, one who has been coding in C since 1980 willI admit my characterisation was over-simplified and thank you for pointing it out. I, too, am in the middle between the two groups (33, and if I was not willing to learn a new language, what should I be supposed to do here? :-) ). Surely all people in this NG are both skilled and open-minded, but obviously I was not talking about them. Maybe I was talking about myself, in a way: I didn't recognize C++ as a way to write better code for a long time, because I could simply write more-or-less C and it would compile it. On the contrary, when I had to face Delphi I was compelled to really learn it (I'll never thank my former boss enough for that). When I finally discovered that C++ has features I had learnt to appreciate in Delphi I was nearly shocked, _then_ I discovered templates and said WOW! Now a C compiler has no chance to compile more than 0.1% of my code :-) Maybe if I had _had_ to learn something in order to use C++ the first time, I could have written better code from the start. D is not nearly so different from C++ as Delphi is, and has no real drawback (Delphi has some, indeed), so I don't think an average, medium-brain-sized newbie, or senior for that matter, needs exactly the same syntax as C++ nor a preprocessor to start using D profitably, while he/she could even benefit from having to recode that 3-year-old module... While I'm on the subject, I think that releasing all the RTL source code would be a great help for people approaching D after having learnt programming with C++ (or C, or Delphi, or <insert language here>). I hope not to be too boring... :-) Ricswitch...That's utter nonsense. On what do you base this? [interesting arguments follow, not quoted for brevity]
Jul 31 2003
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message news:bgak8m$cna$1 digitaldaemon.com..."Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgahju$adu$1 digitaldaemon.com...Indeed.hardlyAs for second nature, one who has been coding in C since 1980 willI admit my characterisation was over-simplified and thank you for pointing it out. I, too, am in the middle between the two groups (33, and if I was not willing to learn a new language, what should I be supposed to do here? :-) ).switch...That's utter nonsense. On what do you base this? [interesting arguments follow, not quoted for brevity]Surely all people in this NG are both skilled and open-minded, butobviouslyI was not talking about them.That's fair. But I would think that the D ng people will be the first disciples (to continue the disturbing religious metaphor from the other thread!), and given the quite large spectrum of talent and experience in the ng, this will form a compelling case for D being taken seriously on a broader scale.Maybe I was talking about myself, in a way: I didn't recognize C++ as awayto write better code for a long time, because I could simply write more-or-less C and it would compile it. On the contrary, when I had tofaceDelphi I was compelled to really learn it (I'll never thank my former boss enough for that). When I finally discovered that C++ has features I had learnt to appreciate in Delphi I was nearly shocked, _then_ I discovered templates and said WOW! Now a C compiler has no chance to compile morethan0.1% of my code :-)I am no adherent to all things C++ - I'm currently writing a book on C++ whose theme is pointing out the flaws! - but I find most of the criticisms of people who do not have a considerable degree of expertise in it to be second-hand at best. There are many things wrong with C++, but it is still the best language out there for most tasks where efficiency, expressiveness and being within shouting distance of the architecture are necessary. Perhaps one of the problems is just how much one needs to learn in order to get that level of expertise. And the push towards template nervana is not helping matters. I do a *lot* of template stuff - despite attempts to unify and simplity (I'm the author of STLSoft, which ships with DMC++) - as well as writing about it, but when I look at some of the other template libraries out there my head hurts as much as the next man. (I have a hypothesis that there are just as many template cowboys now as there were inheritance cowboys a few years ago, they've just swapped working-set-size for number-of-people-I-can-confound-with-my-cleverness.) The language is getting better and more powerful, but there is a bigger wake of people left behind, who consequently move towards Java, .NET, Delphi, and similar middle-tier power languages. I hope and expect that D can fill the gap between these so-called middle-tier languages and the blue-skies that C++ is rushing towards, so that it provides accessibility and simplicity for the (sensible) majority, as well as providing powerful generics and even meta-programming capabilities for those who need to fly higher (for good or ill).Maybe if I had _had_ to learn something in order to use C++ the firsttime,I could have written better code from the start. D is not nearly so different from C++ as Delphi is, and has no real drawback (Delphi hassome,indeed), so I don't think an average, medium-brain-sized newbie, or senior for that matter, needs exactly the same syntax as C++ nor a preprocessortostart using D profitably, while he/she could even benefit from having to recode that 3-year-old module...While I'm on the subject, I think that releasing all the RTL source code would be a great help for people approaching D after having learnt programming with C++ (or C, or Delphi, or <insert language here>).AgreedI hope not to be too boring... :-)Quite the contrary
Jul 31 2003
"Matthew Wilson" <matthew stlsoft.org> wrote in message news:bgaoqt$gj4$1 digitaldaemon.com...I am no adherent to all things C++ - I'm currently writing a book on C++ whose theme is pointing out the flaws! - but I find most of the criticisms of people who do not have a considerable degree of expertise in it to be second-hand at best. There are many things wrong with C++, but it is still the best language out there for most tasks where efficiency,expressivenessand being within shouting distance of the architecture are necessary. Perhaps one of the problems is just how much one needs to learn in ordertoget that level of expertise. And the push towards template nervana is not helping matters. I do a *lot* of template stuff - despite attempts tounifyand simplity (I'm the author of STLSoft, which ships with DMC++) - as well as writing about it, but when I look at some of the other templatelibrariesout there my head hurts as much as the next man. (I have a hypothesis that there are just as many template cowboys now as there were inheritance cowboys a few years ago, they've just swapped working-set-size for number-of-people-I-can-confound-with-my-cleverness.) The language isgettingbetter and more powerful, but there is a bigger wake of people leftbehind,who consequently move towards Java, .NET, Delphi, and similar middle-tier power languages.I admit that C++ templates make my eyeballs hurt. The inventors of STL have discovered an important new way of programming, though, and some aspects of templates are pure genious. But C++ templates are so complicated that they leave most real world programmers behind including many expert coders who won't use them because they know that their successor will just throw their code away because they cannot follow it. There's got to be a better way. A lot of the interest in Java comes from people who reject the complexity of C++. It's too hard to learn, too hard to master, and too hard to debug. (Ever tried to figure out why a template isn't working?) While D does have templates, it incorporates into the core language many things that C++ templates try to address, such as superior string handling. I believe this will make these powerful features much more accessible, and will help people use them correctly and efficiently.I hope and expect that D can fill the gap between these so-called middle-tier languages and the blue-skies that C++ is rushing towards, so that it provides accessibility and simplicity for the (sensible) majority, as well as providing powerful generics and even meta-programming capabilities for those who need to fly higher (for good or ill).Yes, exactly.
Aug 07 2003
"Walter" <walter digitalmars.com> wrote in message news:bgvad0$1qf2$1 digitaldaemon.com...A lot of the interest in Java comes from people who reject the complexityofC++. It's too hard to learn, too hard to master, and too hard to debug. (Ever tried to figure out why a template isn't working?)There is also quite a bit interest in Java for embedded apps (as in embedded in some other app, rather than Java for bare metal programming) because you know (well believe) that a Java servlet/applet/app will not crash your main app (web server, pda, phone etc) if its been written badly, and it only gets the interface to the OS/app its embedded in that the VM vendor/device vendor supplies. with a dynamic compiler that can delete compiled code the memory foot print can be quite small too without much performance penalty. even in non embedded applications Java is a lot more robust than most compiled langs, you can create null pointer or array index exceptions if your code is incorrect, but you can't walk over your own stack frame (or a parent frame) something that in C, C++ is all to easy to do and D creates a few more fun ways to do it too (miss use of array slicing on a stack allocated array, misuse of address of an inner function to name the ones I've tried)
Aug 07 2003
"Walter" <walter digitalmars.com> wrote in message news:bgvad0$1qf2$1 digitaldaemon.com..."Matthew Wilson" <matthew stlsoft.org> wrote in message news:bgaoqt$gj4$1 digitaldaemon.com...criticismsI am no adherent to all things C++ - I'm currently writing a book on C++ whose theme is pointing out the flaws! - but I find most of thestillof people who do not have a considerable degree of expertise in it to be second-hand at best. There are many things wrong with C++, but it isnotthe best language out there for most tasks where efficiency,expressivenessand being within shouting distance of the architecture are necessary. Perhaps one of the problems is just how much one needs to learn in ordertoget that level of expertise. And the push towards template nervana iswellhelping matters. I do a *lot* of template stuff - despite attempts tounifyand simplity (I'm the author of STLSoft, which ships with DMC++) - asthatas writing about it, but when I look at some of the other templatelibrariesout there my head hurts as much as the next man. (I have a hypothesismiddle-tierthere are just as many template cowboys now as there were inheritance cowboys a few years ago, they've just swapped working-set-size for number-of-people-I-can-confound-with-my-cleverness.) The language isgettingbetter and more powerful, but there is a bigger wake of people leftbehind,who consequently move towards Java, .NET, Delphi, and similarhavepower languages.I admit that C++ templates make my eyeballs hurt. The inventors of STLdiscovered an important new way of programming, though, and some aspectsoftemplates are pure genious. But C++ templates are so complicated that they leave most real world programmers behind including many expert coders who won't use them because they know that their successor will just throwtheircode away because they cannot follow it. There's got to be a better way.Me too, and I'm a promulgator of it. (ftr, I think most people need a serious rethink in terms of just they format their templates. Clarity is so often overlooked ...) It's a bizarre position. I get STL as a concept, and well into implementing it, as you know, but I find other people's template, esp. STL-like, almost impossible to understand. Now I'm neither a genius nor a dummy, but I figure if I have a hard time with templates when I do reasonably complex things with them most days, then something's got to give. Having said that, the power is just a must-have, and this is why we won't be seeing anything replace C++ *and* STL for a very long time. Maybe D can be that thing eventually, I dunno, but if it is, it'd better have all the power that C++ + STL has, to even stand a chance.A lot of the interest in Java comes from people who reject the complexityofC++. It's too hard to learn, too hard to master, and too hard to debug. (Ever tried to figure out why a template isn't working?)Usually easy if it's runtime (and you have a decent debugger). _Much_ harder if compile-time.While D does have templates, it incorporates into the core language many things that C++ templates try to address, such as superior stringhandling.I believe this will make these powerful features much more accessible, and will help people use them correctly and efficiently.Maybe. I do hope so, but if they don't all work with and without a generics facility that is equal (or pretty close) to that of C++ + STL then it won't matter (to C++ people, anyway). Perhaps we can get this moving in the next month or two ...majority,I hope and expect that D can fill the gap between these so-called middle-tier languages and the blue-skies that C++ is rushing towards, so that it provides accessibility and simplicity for the (sensible)I take it you're on board then. If/when a group of us get the time and energy to really do a DTL, I take it we can count on your facilitating our demands with frequent, major DMD re-writes? ;)as well as providing powerful generics and even meta-programming capabilities for those who need to fly higher (for good or ill).Yes, exactly.
Aug 07 2003
"Matthew Wilson" <matthew stlsoft.org> wrote in message news:bgvgkc$1vnj$1 digitaldaemon.com...I take it you're on board then. If/when a group of us get the time and energy to really do a DTL, I take it we can count on your facilitating our demands with frequent, major DMD re-writes? ;)Yes, I'm up for working on the syntax of D templates to make a DTL work.
Aug 10 2003
Hi. Matthew Wilson wrote: ...I think there is some merit in trying to reach out to the university students somehow. When they graduate, whatever language they've been told is the best will be forced into use in industry. It happens all the time. There's an unfortunate process at work, that I see going like this: -- Someone invents a really very difficult programming language to use or understand, and gets some good hype with some new buzz words, and perhaps a few real inovations. -- The smartest university students want to learn it, partly because only smart guys can, and they want to prove themselves. They dive in, master it, and then want to use it. -- Industry hires these smartest guys, and get pushed into using the new difficult language on new projects. -- The average programmers get hired to maintain the code the smart guys wrote, and can't understand it or work with it. They totally mess it up. For C, the draw was difficult pointers and type declarations. Do you remember "The C Puzzle Book"? All the smart students studied it. How about the "Obfuscated C Code Contest"? C++ totally outclassed C in complexity, and has some concepts that most programmers will never understand or use. Smart students were attracted to it like moths to a flame. C++ was a language so complex, they could gain understanding of it for months (if they really are smart), or years (if they're just above average). It gave them a way to express code that clearly demonstrated their intellect even if the problem was something simple, like "Hello, world". I think one problem for D with the university crowd is that it's a bit to simple. Design by contract, and unit test are great buzz words, but a bit too easy to use and understand. Also, QA features are for the masses, not guys who preffer *p->q++**++ to a subroutine call like "moveToNextWord". If it's not dangerous, and difficult, it will have a hard time being hip with the smart students. Bill P.S. I seem to keep posting problems without posting solutions, so here's some suggestions for how to make D seem more difficult. Perhaps someone could write "The D Puzzle Book". Conversions of D strings to C strings would be a good one to start with :-). How about the 9 different ways to delcare "bool", and the tricky conversion bugs that result? Include hard to understand features to help smart guys differentiate themselves: -- Multimethods -- Virtual Classes -- Template frameworks -- Functional programming -- Sather's looping constructs -- Compile time mirror classes In fact, if we don't include these kinds of things, someone is sure to come out with D++ shortly :-). Smart guys just can't help themselves.OTOH, there are lots of newbies out there, and they are the future.They'll only be the future if they learn from people with more experience!
Jul 31 2003
"Bill Cox" <bill viasic.com> ha scritto nel messaggio news:3F291E4B.2020208 viasic.com...There's an unfortunate process at work, that I see going like this: [...]ROTFL! Ric P.S.: I agree with the serious parts of your post. I just hope your proposal about making D more complicated is not among them.
Jul 31 2003
Riccardo De Agostini wrote:"Bill Cox" <bill viasic.com> ha scritto nel messaggio news:3F291E4B.2020208 viasic.com...No, I wasn't serious. I think the recent posts on this group are right-on. D may become popular if we can paste together good libs, IDE support, and so on. I just wish there were more avenues that could be taken. BillThere's an unfortunate process at work, that I see going like this: [...]ROTFL! Ric P.S.: I agree with the serious parts of your post. I just hope your proposal about making D more complicated is not among them.
Aug 01 2003
"Bill Cox" <bill viasic.com> wrote in message news:3F291E4B.2020208 viasic.com...How about the "Obfuscated C Code Contest"?LOL. Did you know that I won that contest years back? I can write horrible code with the worst of them <g>.In fact, if we don't include these kinds of things, someone is sure to come out with D++ shortly :-). Smart guys just can't help themselves.We could start with the Obfuscated D Code Contest!
Aug 07 2003
Maybe we're trying to byte off more than we can chew. For my part, I am much more interested in writing libraries than in writing applications, but for others it is the other way round. * We need good libraries to support the language development, a consistent and efficient implementation of applications, etc. etc. (All the reasons one needs libraries, basically). * We need (at least one) good applications to promote the library. We can get it noticed by writing articles in the mainstream press (btw, it looks like two of mine are coming out next month in a WDN online supplement), and such, but until there is a significant piece of "wow"-ing software out there, people are going to be "so-what"-ing it. Unfortunately, I don't believe that an autocratic/top-down approach is going to work. I think D needs a libraries group (DLG), composed of interested and experienced volunteers, ratified by big W, of course. Library submissions would be made, or requested, from work carried out in *real* projects. These real projects don't have to be massive; oftentimes a simple utility can tease out a neat little library . It is almost always the case that good software is written twice, so let (in fact encourage) people do their own thing with their own applications/libraries. Each person will learn more about D in the process, and therefore be able to offer reasoned debate during the library ratification process. I think two types of libraries should be considered: 1. SDL / Phobos The libraries group would ensure that Phobos would be as small as is reasonable and no smaller. In other words, all essential features go in here, but nothing domain/application specific These libs would be binary, and shipped with the compiler, and probably automatically linked in (though with an optional -nosdl flag to not do so). Whether they have source provided or not is, I guess, up to Walter at this time. 2. Domain/Application/Technology specific libraries For my part I do not care whether these are also "owned" by D or whether they exist as 3rd-party, but DLG-sanctioned, libraries. For example, I did some D performance_counter libs (http://synsoft.org/d.html) for some articles I wrote (the ones coming out in Aug, hopefully) which could either exist as a discrete entity with the DLG mark of approval, or could be rolled into a DMD-owned thing. (ftr, I've not got round to open-sourcing them, but plan to as soon as I get round to it.) hence: 2a. DMD supplemental libraries - owned by DMD, shipped with the compiler 2b. 3rd party DLG-ratified libraries - owned by whomever, probably open-source, may/may not be shipped with the compiler The aims/responsiblities of the DLG would include: - sniff out good potential libs to give the DLG treatment and approval - respond to submissions for potential libs - ensure that principles of efficiency, orthogonality, robustness, etc., are adhered to, and be *helpful* to submittors on how to rectify any such deficits - ensure that libs come along with documentation, test cases, samples, etc. - maintain a sense of proportion about their own importance (lord knows there are enough prima-donnas in other languages standards processes!) - etc. So who would serve on the DLG? - people expert in D - Burton, Sean, etc. etc. - representatives of DM - I think that means Walter!! - people expert in writing libs - people who can manage these kind of things - people with enough time - that probably eliminates everyone! :( How would DLG work? I have no fixed idea. However, I would think there would be a centralised (email-based?) notification system of proposals, regular distribution of the latest candidates and their review progress. Each library submission would have to fulfil initial criteria (i.e. include minimum amount of docs, test cases, etc.), and go under the nose of, say, three DGL members. The downside is that all of this sounds like it might take a lot of effort. I guess we'd just have to see how it goes. All of this would be meaningful given sufficient stability and maturity in D and DMD. I've not got the feeling yet that that is the case (although I'm happy to be told otherwise). So it may be too soon for DLG, or it may the right time. I've just thrown all this out before breakfast, so may have overlooked some obvious reasons against. Shoot away. What do you all think? Matthew
Jul 30 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bg9lde$2gct$1 digitaldaemon.com...Unfortunately, I don't believe that an autocratic/top-down approach isgoingto work. I think D needs a libraries group (DLG), composed of interestedandexperienced volunteers, ratified by big W, of course.Here's one (as long as Walter agrees, that is...)Library submissions would be made, or requested, from work carried out in *real* projects. These real projects don't have to be massive; oftentimesasimple utility can tease out a neat little library .Especially if it works better, and its source is smaller and more readable, than a comparable utility written in another language, say C++ for instance... D surely has the potential for this.I think two types of libraries should be considered: 1. SDL / Phobos The libraries group would ensure that Phobos would be as small as is reasonable and no smaller. In other words, all essential features go in here, but nothing domain/application specific These libs would be binary, and shipped with the compiler, and probably automatically linked in (though with an optional -nosdl flag to not doso).Whether they have source provided or not is, I guess, up to Walter at this time. 2. Domain/Application/Technology specific libraries For my part I do not care whether these are also "owned" by D or whether they exist as 3rd-party, but DLG-sanctioned, libraries. [...] 2a. DMD supplemental libraries - owned by DMD, shipped with the compiler 2b. 3rd party DLG-ratified libraries - owned by whomever, probably open-source, may/may not be shipped with the compilerFWIW you have my vote!The aims/responsiblities of the DLG would include: - sniff out good potential libs to give the DLG treatment and approval - respond to submissions for potential libs - ensure that principles of efficiency, orthogonality, robustness, etc., are adhered to, and be *helpful* to submittors on how to rectify any such deficits - ensure that libs come along with documentation, test cases, samples,etc.- maintain a sense of proportion about their own importance (lord knows there are enough prima-donnas in other languages standards processes!) - etc.Things begin to take shape... and it's a shape I personally like a lot.So who would serve on the DLG? [...] How would DLG work? [...] The downside is that all of this sounds like it might take a lot ofeffort.I guess we'd just have to see how it goes. All of this would be meaningful given sufficient stability and maturity inDand DMD. I've not got the feeling yet that that is the case (although I'm happy to be told otherwise). So it may be too soon for DLG, or it may the right time.IMHO, just as real-world apps are going to shape library development, DLG's work is going to help the final rush towards DMD 1.0.I've just thrown all this out before breakfast, so may have overlookedsomeobvious reasons against. Shoot away.I had breakfast 2 hours ago, so I have no excuses. :-) Ric
Jul 31 2003
Matthew Wilson wrote:The libraries group would ensure that Phobos would be as small as is reasonable and no smaller. In other words, all essential features go in here, but nothing domain/application specificIMO Phobos should be cannibalised. The purpose of having a default install set is because dealing with the auto-installer is too difficult; so we should make the auto-installer easy to use and browse with. It should also be configurable, so that loading it with a default set of packages (dmd, dmc, a few libraries) should be easy. SDL bad. I don't like acronyms. They're all taken and they convey no information.These libs would be binary, and shipped with the compiler, and probably automatically linked in (though with an optional -nosdl flag to not do so). Whether they have source provided or not is, I guess, up to Walter at this time.No automatic linking. The source defines the libraries it uses.The aims/responsiblities of the DLG would include: - sniff out good potential libs to give the DLG treatment and approval - respond to submissions for potential libs - ensure that principles of efficiency, orthogonality, robustness, etc., are adhered to, and be *helpful* to submittors on how to rectify any such deficits - ensure that libs come along with documentation, test cases, samples, etc. - maintain a sense of proportion about their own importance (lord knows there are enough prima-donnas in other languages standards processes!) - etc.Perhaps over time, but at this point the library group would be implementing the standard library itself.How would DLG work? I have no fixed idea. However, I would think there would be a centralised (email-based?) notification system of proposals, regular distribution of the latest candidates and their review progress. Each library submission would have to fulfil initial criteria (i.e. include minimum amount of docs, test cases, etc.), and go under the nose of, say, three DGL members.I think it would be best to start with a mailing list and a CVS and expand according to what turns out to be necessary.All of this would be meaningful given sufficient stability and maturity in D and DMD. I've not got the feeling yet that that is the case (although I'm happy to be told otherwise). So it may be too soon for DLG, or it may the right time.It's self-feeding. D can't be mature until it has a good library. Not having a good library decreases maturity over time due to reimplementations. I think I've implemented file stat and directory listing six times over the year; the first time was the most comprehensive, the rest I just wanted to get the task over with.
Aug 03 2003
SDL bad. I don't like acronyms. They're all taken and they convey no information.FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.
Aug 03 2003
This is all kind of missing the point. If I gave the impression that I thought the particular, made-up-on-the-spot, acronyms, were important, or even that giving the things discussed acronyms at all was important, let me recant now. What I was interested in learning was whether anybody (a) thought it worthwhile trying to get some structure to the arbitrary individual efforts going on atm, and (b) whether anyone would be prepared to invest of themselves in making such a structure eventuate. Matthew "Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message news:bgk875$e1r$1 digitaldaemon.com...SDL bad. I don't like acronyms. They're all taken and they convey no information.FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.
Aug 03 2003
Hehe, i like phobos too btw.(a) thought it worthwhile trying to get some structure to the arbitrary individualeffortsgoing on atmDefinetly! I think this is very important, and I think we should stop just talking about it and get started.(b) whether anyone would be prepared to invest of themselves in making such a structure eventuate.I'll do what I can, though don't think Im completely qualified for the base library, I'm going to start work on binding libcurl (soon I swear!). Given the modest nature of the people on this list , I think we might have to vote people on, wether they like it or not! Charles "Matthew Wilson" <matthew stlsoft.org> wrote in message news:bgkd79$ii4$1 digitaldaemon.com...This is all kind of missing the point. If I gave the impression that I thought the particular, made-up-on-the-spot, acronyms, were important, or even that giving the things discussed acronyms at all was important, letmerecant now. What I was interested in learning was whether anybody (a) thought it worthwhile trying to get some structure to the arbitrary individualeffortsgoing on atm, and (b) whether anyone would be prepared to invest of themselves in making such a structure eventuate. Matthew "Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message news:bgk875$e1r$1 digitaldaemon.com...theSDL bad. I don't like acronyms. They're all taken and they convey no information.FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to"Digital Mars" name.
Aug 03 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgkd79$ii4$1 digitaldaemon.com...(a) thought it worthwhile trying to get some structure to the arbitrary individual efforts going on atmAbsolutely. Some people are already developing D libraries, naming them after the author (import net.BurtonRadons.*), which is correct; but "core" libraries such as file system access, etc. deserve something like "import std.files" if not even "import files". Besides, I think that having to type "import net.RiccardoDeAgostini.*" could discourage even myself from using my own libraries (as soon as I have some ready, that is).(b) whether anyone would be prepared to invest of themselves in making such a structure eventuate.My objective is to replace C++ as the "standard" language at work, with something as comfortable as Delphi. D fits perfectly (also because of its first-sight resemblance with C, which is a strong psychological weapon because my boss has been programming in C for what seems to be ages). Would I invest some of my time in order to make my job easier and more fun? You bet!! Ric
Aug 04 2003
Riccardo De Agostini wrote:"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgkd79$ii4$1 digitaldaemon.com...Arrgh. "import files" will collide with any Sourcefile "files.d" that someone might use in his own projects. So don't even think about this. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com(a) thought it worthwhile trying to get some structure to the arbitrary individual efforts going on atmAbsolutely. Some people are already developing D libraries, naming them after the author (import net.BurtonRadons.*), which is correct; but "core" libraries such as file system access, etc. deserve something like "import std.files" if not even "import files".
Aug 04 2003
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio news:3F2E36BA.21A935A9 hls.via.at...Arrgh. "import files" will collide with any Sourcefile "files.d" that someone might use in his own projects. So don't even think about this.As a matter of fact, I was not. :-) Just making an example. A rather bad example, as it turns out. Thinking better, the need to avoid name collisions could easily make the standard library end up with all module names starting with "__std__" or something equally useless and/or weird. So my preference goes, definitely, to a "std" folder and thus a "std." prefix in imports. Ric
Aug 04 2003
Riccardo De Agostini wrote:"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio news:3F2E36BA.21A935A9 hls.via.at...I think there have been a number of discussions about this. As we have already c.stdio module names like d.files might also be nice and short. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.comArrgh. "import files" will collide with any Sourcefile "files.d" that someone might use in his own projects. So don't even think about this.As a matter of fact, I was not. :-) Just making an example. A rather bad example, as it turns out. Thinking better, the need to avoid name collisions could easily make the standard library end up with all module names starting with "__std__" or something equally useless and/or weird. So my preference goes, definitely, to a "std" folder and thus a "std." prefix in imports.
Aug 04 2003
"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message news:bgk875$e1r$1 digitaldaemon.com...I'm sick of acronyms, too.SDL bad. I don't like acronyms. They're all taken and they convey no information.FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.
Aug 16 2003
In article <bhknmd$1nqb$4 digitaldaemon.com>, Walter says..."Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message news:bgk875$e1r$1 digitaldaemon.com...It also stands for System Design Language,a design notation still used in telecoms.SDL bad. I don't like acronyms. They're all taken and they convey no information.FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C.I don't. It ties the name to DigitalMars, rendering it forever niche. If D is going to get more widespread usage it has to have a life outside of DigitalMars. -Andrew MarlowI kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name.
Aug 17 2003
"Burton Radons" <loth users.sourceforge.net> ha scritto nel messaggio news:bgjeod$2nvl$1 digitaldaemon.com...IMO Phobos should be cannibalised.Munch, munch, crunch, crunch... :-)No automatic linking. The source defines the libraries it uses.Agree 100%[...] at this point the library group would be implementing the standard library itself. [...] I think it would be best to start with a mailing list and a CVS and expand according to what turns out to be necessary. [...] It's self-feeding. D can't be mature until it has a good library. Not having a good library decreases maturity over time due to reimplementations. I think I've implemented file stat and directory listing six times over the year; the first time was the most comprehensive, the rest I just wanted to get the task over with.Agree 120%. Besides, this demonstrates (as if there were any need to do so) that you're smarter than wanting to type "net.BurtonRadons" hundreds of times just for the glory :-) Ric
Aug 04 2003
Burton Radons wrote:No automatic linking. The source defines the libraries it uses.I agree with this. I also think the libraries should be modular, so that a person could include "d.file" or "d.stream" but not include "d.win32" or "d.string". I have experienced trying to import my own module for something and having to mangle the name of routines or classes from what I prefer to prevent collision with phobos.
Aug 04 2003
I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especially the unittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.
Aug 16 2003
Great I was wondering about this, I remember alot of activity but don't remember what became of it. I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this ? I'm not trying to elect myself as leader to this, I just want to see it get off the ground. Thanks, lets hear some ideas! Charles "Walter" <walter digitalmars.com> wrote in message news:bhkq1t$1urm$1 digitaldaemon.com...I want to encourage everyone to help out with the library. My primaryfocus,as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, willtakeon the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class,sothe smallest app pulled in the entire library. Library modules should beasdecoupled as practical. Calling a directory function shouldn't pull in100kof bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especiallytheunittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.
Aug 16 2003
"Charles Sanders" <sanders-consulting comcast.net> wrote in message news:bhm2ns$3dd$1 digitaldaemon.com...Great I was wondering about this, I remember alot of activity but don't remember what became of it. I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this? I always prefered perforce to cvs http://www.perforce.com/ as this is an open source project (does not need to be GPL but does have to contain "Redistribution and use in source and binary forms, with or without modification, are permitted" ) not sure if that is acceptable,Walter what where your plans for the phobos libs licence?I'm not trying to elect myself as leader to this, I just want to see itgetoff the ground.I've started have a play getting some Java like Stream libs started as I find the phobos Stream too much like FILE *, and perfer the Java approach where InputStream is just that. but I've run into a few issues first wchar[] is not very well supported Exception for instance can not have a wchar[] msg seems to me that it would be best if all apis used wchar as char-> wchar ([] or not) can be performed without loss of information (the converse not). the wchar windows api calls is missing too (well as is a lot of the win32 API) that is solvable by using the ported headers I've done and getting them tested (I'm certain that there may be alignment and other errors in there there is nearly a meg of code however I do not believe that it is realy legal for me to redistribute the work I've done (Bill if your reading this, and want to sue me I'll only accept the summons if you deliver it in person!) (I've attached the MS SDK licence) from what I read I can redist modified code only if I can make an object lib (not realy helpful) Walter I assume you have a licence to redistribute the MS headers, does it cover redist of modified headers and does it extend to a) ppl outside your company b) the latest SDK ? otherwise the first task as I see it it so get a licence to port the MS headers without that we are dead in the water. (if case a false I wonder if we can become unpayed members of the DM staff to get around the licence agreement(s)). I have to revisit python to see how/what the layout is like but module and templates are causing me some grief. again I like the Java way, there is nothing worse (to me) than having to search for where something is. if I want the class phobos.io.InputStream ... I'd like to know A how to get it and B how to import it .. import phobos.io.InputStream; would seem logical or (import phobos.io; maybe) if I'm right about the D modules Object (which is defined in object.d) has the fully qualified name `object.Object` if I start putting each class into a separate file (and if this is going to be a multi developer open source lib I think you'll all agree that, that will be a lot nicer that a wacking great phobos/io.d (or whatever) file with all the stream and other io classes) say I use phobos/io/InputStream.d for InputStream etc its fully qualified name is then phobos.io.InputStream.InputStream; I could make is phobos/base/InputStream.d; => phobos.base.InputStream.InputStream; and have a alias in the phobos/io.d file (alias phobos.base.InputStream.InputStream InputStream;) but thats a lot of typing and prone to errors all to just get phobos.io.InputStream as a fully qualified name and to get the implementation into a file on its own. like templates (which are almost modules within modules) I think there there is too much depth in the D names, I think D needs a way to create a file that only contains one item, be that a template, class, struct or other. so import a.b.c; looks for a/b/c.d as it does now; only the item imported may be a.b.c rather than a.b.c.t.c or a.b.c.c etc; begin 666 License.htm M:'1M;#L 8VAA<G-E=#UW:6YD;W=S+3$R-3(B/ T*"0D\;65T82!N86UE/2)' M8V4-" E[9F]N="UF86UI;'DZ(D9R86YK;&EN($=O=&AI8R!$96UI($-O;F0B M8V4-" E[9F]N="UF86UI;'DZ(D9R86YK;&EN($=O=&AI8R!";V]K(CL-" EP M:6YI=&EO;G, *B\-"B!P+DUS;TYO<FUA;"P ;&DN37-O3F]R;6%L+"!D:78N M($YE=R!2;VUA;B([?0T*<"XT3$%087)A2&5A9"P ;&DN-$Q!4&%R84AE860L M(&1I=BXT3$%087)A2&5A9 T*"7MM87)G:6XM=&]P.C8N,'!T.PT*"6UA<F=I M;BUR:6=H=#HP M=#HQ M="US:7IE.C N,'!T.PT*"69O;G0M9F%M:6QY.B)&<F%N:VQI;B!';W1H:6, M3$%";V1Y+"!L:2XS3$%";V1Y+"!D:78N,TQ!0F]D>0T*"7MM87)G:6XM=&]P M.C,N,'!T.PT*"6UA<F=I;BUR:6=H=#HP M=#L-" EL:6YE+6AE:6=H=#HY+C!P=#L- M=&]M.C!I;CL-" EM87)G:6XM;&5F=#HY M<F%N:VQI;B!';W1H:6, 0F]O:R([?0T*<"XS:4YU;6)E<F5D,FYD;&5V96PL M(&QI+C-I3G5M8F5R960R;F1L979E;"P 9&EV+C-I3G5M8F5R960R;F1L979E M; T*"7MM87)G:6XM=&]P.C,N,'!T.PT*"6UA<F=I;BUR:6=H=#HP M"6QI;F4M:&5I9VAT.C N,'!T.PT*"69O;G0M<VEZ93HW+C!P=#L-" EF;VYT M+69A;6EL>3HB1G)A;FML:6X 1V]T:&EC($)O;VLB.PT*"6-O;&]R.F)L86-K M.WT-"G N,F%&<F5N8VA3=6)H96%D+"!L:2XR849R96YC:%-U8FAE860L(&1I M=BXR849R96YC:%-U8FAE860-" E[;6%R9VEN+71O<#HQ M9VEN+7)I9VAT.C!I;CL-" EM87)G:6XM8F]T=&]M.C!I;CL-" EM87)G:6XM M;&5F=#HP M9VAT.C$R+C!P=#L-" EF;VYT+7-I>F4Z,3$N,'!T.PT*"69O;G0M9F%M:6QY M=&]M.C!I;CL-" EM87)G:6XM;&5F=#HQ M(D9R86YK;&EN($=O=&AI8R!$96UI($-O;F0B.WT-"G N,DQ!4W5B:&5A9"P M;&DN,DQ!4W5B:&5A9"P 9&EV+C),05-U8FAE860-" E[;6%R9VEN+71O<#HV M+C!P=#L- M=#L-" EL:6YE+6AE:6=H=#HQ M" EF;VYT+69A;6EL>3HB1G)A;FML:6X 1V]T:&EC($1E;6D 0V]N9"([?0T* M<"XS3$%";V1Y0F5F;W)E,'!T+"!L:2XS3$%";V1Y0F5F;W)E,'!T+"!D:78N M,TQ!0F]D>4)E9F]R93!P= T*"7MM87)G:6XM=&]P.C!I;CL-" EM87)G:6XM M9G0Z,&EN.PT*"69O;G0M<VEZ93HX+C!P=#L-" EF;VYT+69A;6EL>3HB1G)A M;FML:6X 1V]T:&EC($)O;VLB.WT-"G-P86XN,TQ!0F]D>4-H87(-" E[9F]N M:6, 0F]O:R([?0T*0'!A9V4 4V5C=&EO;C$-" E[<VEZ93HX+C5I;B Q,2XP M96-T:6]N,0T*"7MP86=E.E-E8W1I;VXQ.WT-"B O*B!,:7-T($1E9FEN:71I M"0D\<"!C;&%S<STB,5-E8W1I;VY(96%D(B!S='EL93TG;6%R9VEN+71O<#HP M:6X[;6%R9VEN+7)I9VAT.C!I;CMM87)G:6XM8F]T=&]M. T*,RXP<'0[;6%R M9VEN+6QE9G0Z,&EN.W1E>'0M:6YD96YT.C!I;CML:6YE+6AE:6=H=#IN;W)M M86PG/CQB/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M M:6QY.B)";V]K($%N=&EQ=6$B)SY%3D0M55-%4B!,24-%3E-%($%'4D5%345. M5 T*1D]2($U)0U)/4T]&5"!33T945T%213PO<W!A;CX\+V(^/"]P/ T*"0D) M/' 8VQA<W,](C%396-T:6]N2&5A9"( <W1Y;&4])VUA<F=I;BUT;W Z,&EN M.VUA<F=I;BUR:6=H=#HP:6X[;6%R9VEN+6)O='1O;3H-"C,N,'!T.VUA<F=I M;BUL969T.C!I;CMT97AT+6EN9&5N=#HP:6X[;&EN92UH96EG:'0Z;F]R;6%L M051&3U)-(%-/1E1705)%($1%5D5,3U!-14Y4($M)5#PO M"0D\<"!C;&%S<STB,DQ!4W5B:&5A9"( <W1Y;&4])VUA<F=I;BUT;W Z,&EN M.VUA<F=I;BUR:6=H=#HM+C U<'0[;6%R9VEN+6)O='1O;3H-"C,N,'!T.VUA M<F=I;BUL969T.C!I;CML:6YE+6AE:6=H=#IN;W)M86PG/CQB/CQS<&%N('-T M>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.PT*9F]N="UF86UI;'DZ(D)O;VL 06YT M:7%U82(G/DE-4$]25$%.5)=214%$($-!4D5&54Q,63H /"]S<&%N/CPO8CX\ M<W!A;B!S='EL93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O M*)-%54Q!E"D :7, 82!L96=A;"!A9W)E96UE;G0 8F5T=V5E;B!Y;W4 *&5I M=&AE<B!A;B!I;F1I=FED=6%L(&]R(&$-"G-I;F=L92!E;G1I='DI(&%N9"!- M:6-R;W-O9G0 0V]R<&]R871I;VX 9F]R('1H92!-:6-R;W-O9G0 <V]F='=A M<F4 =&AA= T*86-C;VUP86YI97, =&AI<R!%54Q!+"!W:&EC:"!I;F-L=61E M<R!C;VUP=71E<B!S;V9T=V%R92!A;F0 ;6%Y(&EN8VQU9&4-"F%S<V]C:6%T M960 ;65D:6$L('!R:6YT960 ;6%T97)I86QS+""3;VYL:6YEE"!O<B!E;&5C M=')O;FEC(&1O8W5M96YT871I;VXL(&%N9 T*26YT97)N970M8F%S960 <V5R M=FEC97, *)-3;V9T=V%R990I+J 06X 86UE;F1M96YT(&]R(&%D9&5N9'5M M('1O('1H:7, 155,00T*;6%Y(&%C8V]M<&%N>2!T:&4 4V]F='=A<F4NH" \ M8CY93U4 04=2144 5$\ 0D4 0D]53D0 0ED 5$A%(%1%4DU3($]&(%1(25, M5TE312!54TE.1R!42$4 4T]&5%=!4D4N($E&(%E/52!$3R!.3U0 04=2144L M5%=!4D4[(%E/52!-05D 4D5455).($E4(%1/(%E/55( 4$Q!0T4 3T8 4%52 M12X\+V(^/"]S<&%N/CPO<#X-" D)"3QD:78 <W1Y;&4])V)O<F1E<CIN;VYE M.V)O<F1E<BUT;W Z<V]L:60 =VEN9&]W=&5X=" Q+C!P=#MP861D:6YG.C!I M='EL93TG;6%R9VEN+71O<#HP:6X[;6%R9VEN+7)I9VAT.C!I;CMM87)G:6XM M8F]T=&]M.C,N,'!T.PT*;6%R9VEN+6QE9G0Z,&EN.VQI;F4M:&5I9VAT.FYO M<FUA;"<^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,2XP<'0[9F]N="UF86UI M9&EV/ T*"0D)/' 8VQA<W,](DUS;TYO<FUA;"( <W1Y;&4])VUA<F=I;BUB M;W1T;VTZ,RXP<'0G/CQB/CQS<&%N('-T>6QE/2=F;VYT+69A;6EL>3H-"B)" M;V]K($%N=&EQ=6$B)SXQ+J" H*" H*" ($=204Y4($]&($Q)0T5.4T4\+W-P M86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT+69A;6EL>3H-"B)";V]K($%N=&EQ M=6$B)SXNH"!-:6-R;W-O9G0 9W)A;G1S('EO=2!T:&4 <FEG:'1S(&1E<V-R M:6)E9"!I;B!T:&ES($553$$-"G!R;W9I9&5D('1H870 >6]U(&-O;7!L>2!W M:71H(&%L;"!T97)M<R!A;F0 8V]N9&ET:6]N<R!O9B!T:&ES($553$$NH" \ M+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](DUS;TYO<FUA;"( <W1Y;&4])VUA M<F=I;BUB;W1T;VTZ,RXP<'0[=&5X="UI;F1E;G0Z+C5I;B<^/'-P86X <W1Y M;&4])V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SXQ+C& H*" H* /&(^ M/&D^1V5N97)A;" -" D)"0D)"0E,:6-E;G-E($=R86YT/"]I/CPO8CXNH T* M36EC<F]S;V9T(&=R86YT<R!Y;W4 82!L:6UI=&5D+"!N;VYE>&-L=7-I=F4 M;&EC96YS92!T;R!U<V4 =&AE(%-O9G1W87)E+"!A;F0-"G1O(&UA:V4 86YD M('5S92!C;W!I97, ;V8 =&AE(%-O9G1W87)E+"!F;W( =&AE('!U<G!O<V5S M(&]F(&1E<VEG;FEN9RP-"F1E=F5L;W!I;F< 86YD('1E<W1I;F< >6]U<B!S M;V9T=V%R92!A<'!L:6-A=&EO;G, 9F]R('5S92!W:71H(&%N>2!V97)S:6]N M('-Y<W1E;2!F;W( <&5R<V]N86P 8V]M<'5T97)S(&]R('-E<G9E<G,-"BB3 M36EC<F]S;V9T($]P97)A=&EN9R!3>7-T96T 4')O9'5C=)0I+J /"]S<&%N M/CPO<#X-" D)"3QP(&-L87-S/2)-<V].;W)M86PB('-T>6QE/2=M87)G:6XM M8F]T=&]M.C,N,'!T.W1E>'0M:6YD96YT.BXU:6XG/CQS<&%N('-T>6QE/2=F M;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,2XRH*" H*" (#QB/CQI/E-H M(%-E<G9E<B!3;V9T=V%R92!$979E;&]P;65N="!+:70-"BB34U!34T1+E"DN MH"!);B!A9&1I=&EO;B!T;R!T:&4 ;&EC96YS92!G<F%N=&5D(&EN(%-E8W1I M;VX ,2XQ+"!-:6-R;W-O9G0-"F=R86YT<R!Y;W4 82!L:6UI=&5D+"!N;VYE M>&-L=7-I=F4 ;&EC96YS92!T;R!M;V1I9GD =&AE('-A;7!L92!S;W5R8V4 M8V]D90T*;&]C871E9"!I;B!T:&4 4U!34T1+('-O;&5L>2!T;R!D97-I9VXL M(&1E=F5L;W L(&%N9"!T97-T('EO=7( 87!P;&EC871I;VX-"FEN=&5R;F%L M;'D =VET:&EN('EO=7( ;W)G86YI>F%T:6]N+J 66]U<B!E;G1I<F4 ;&EC M96YS92!U;F1E<B!T:&ES($553$$ =VET: T*<F5S<&5C="!T;R!T:&4 4U!3 M4T1+(&ES(&-O;F1I=&EO;F5D(&]N('EO=7( ;F]T('5S:6YG('1H92!34%-3 M:71H(&9I;&4 9F]R;6%T<R!I;F1E>&5D(&)Y($UI8W)O<V]F="!3:&%R95!O M8VQA<W,](DUS;TYO<FUA;"( <W1Y;&4])VUA<F=I;BUB;W1T;VTZ,RXP<'0G M/CQB/CQS<&%N('-T>6QE/2=F;VYT+69A;6EL>3H-"B)";V]K($%N=&EQ=6$B M)SXR+J" H*" H*" (#QS<&%N('-T>6QE/2=T97AT+71R86YS9F]R;3IU<'!E M<F-A<V4G/D%D9&ET:6]N86P-"DQI8V5N<V4 4FEG:'1SEU)E9&ES=')I8G5T M8VQA<W,](DUS;TYO<FUA;"( <W1Y;&4])VUA<F=I;BUB;W1T;VTZ,RXP<'0[ M=&5X="UI;F1E;G0Z+C5I;B<^/'-P86X <W1Y;&4])V9O;G0M9F%M:6QY.B)" M;V]K($%N=&EQ=6$B)SXR+C& H*" H* /&(^/&D^4V]U<F-E( T*"0D)"0D) M"4-O9&4\+VD^/"]B/BZ ()-3;W5R8V4-"D-O9&64(&UE86YS('-O=7)C92!C M;V1E('1H870 :7, ;&]C871E9"!I;B!A;GD 9&ER96-T;W)Y(&]R('-U8BUD M:7)E8W1O<GD ;F%M960-"I-S86UP;&5SE"!I;B!T:&4 4V]F='=A<F4 ;W( M=&AA="!I<R!O=&AE<G=I<V4 :61E;G1I9FEE9"!A<R!S86UP;&4 8V]D92!I M;B!T:&4-"E-O9G1W87)E+"!O=&AE<B!T:&%N('-O=7)C92!C;V1E(&EN8VQU M9&5D(&EN('1H92!34%-31$LL(&]R(&ES(&ED96YT:69I960 87,-"DUI8W)O M<V]F="!&;W5N9&%T:6]N($-L87-S($QI8G)A<FEE<R HDTU&0Y0I+"!496UP M*2Z ($UI8W)O<V]F="!G<F%N=', >6]U(&$ ;&EM:71E9"P ;F]N97AC;'5S M:79E(&QI8V5N<V4 *&$I)FYB<W [=&\-"G5S92!A;F0 ;6]D:69Y(&%N>2!3 M;W5R8V4 0V]D92!T;R!D97-I9VXL(&1E=F5L;W L(&%N9"!T97-T('EO=7( M<V]F='=A<F4-"F%P<&QI8V%T:6]N<SN (&%N9" H8BDF;F)S<#MT;R!M86ME M(&%N9"!D:7-T<FEB=71E(&-O<&EE<R!O9B!T:&4 4V]U<F-E($-O9&4-"F%N M9"!Y;W5R(&UO9&EF:6-A=&EO;G,L('-U8FIE8W0 =&\ >6]U<B!C;VUP;&EA M;F-E('=I=& 4V5C=&EO;B S+J /"]S<&%N/CPO<#X-" D)"3QP(&-L87-S M/2)-<V].;W)M86PB('-T>6QE/2=M87)G:6XM8F]T=&]M.C,N,'!T.W1E>'0M M:6YD96YT.BXU:6XG/CQS<&%N('-T>6QE/2=F;VYT+69A;6EL>3HB0F]O:R!! M;G1I<75A(B<^,BXRH*" H*" (#QB/CQI/E)E9&ES=')I8G5T86)L92 -" D) M=V%R92!T:&%T(&%R92!L:7-T960 :6X =&AE('1E>'0 9FEL90T*7$QI8V5N M<V5<4F5D:7-T+G1X="!C;VQL96-T:79E;'D 8V]N<W1I='5T92"34F5D:7-T M:71E9"P ;F]N97AC;'5S:79E(&QI8V5N<V4 =&\ <F5P<F]D=6-E(&%N9"!D M92!F;W)M(&]N;'DL('-U8FIE8W0 =&\ >6]U<B!C;VUP;&EA;F-E('=I=& M4V5C=&EO; T*,RZ (#PO M;6%L(B!S='EL93TG;6%R9VEN+6)O='1O;3HS+C!P="<^/&(^/'-P86X <W1Y M;&4])V9O;G0M9F%M:6QY. T*(D)O;VL 06YT:7%U82(G/C,NH*" H*" H* M24].4SPO<W!A;CX\+V(^/"]P/ T*"0D)/' 8VQA<W,](DUS;TYO<FUA;"( M<W1Y;&4])VUA<F=I;BUB;W1T;VTZ,RXP<'0[=&5X="UI;F1E;G0Z+C5I;B<^ M/'-P86X <W1Y;&4])V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SXS+C& M:6)U=&4 4V]U<F-E($-O9&4L(&%N>2!M;V1I9FEC871I;VYS('EO=2!M86ME M961I<W1R:6)U=&%B;&4 0V]D92 H8V]L;&5C=&EV96QY+""34F5D:7-T<FEB M=71A8FQE<Y0I(&%R90T*8V]N9&ET:6]N960 ;VX =&AE(&9O;&QO=VEN9SJ M("AA*29N8G-P.WEO=2!W:6QL(&1I<W1R:6)U=&4 4F5D:7-T<FEB=71A8FQE M<PT*;VYL>2!I;B!O8FIE8W0 8V]D92!F;W)M(&%N9"!I;B!C;VYJ=6YC=&EO M;B!W:71H(&%N9"!A<R!A('!A<G0 ;V8 82!S;V9T=V%R90T*87!P;&EC871I M;VX 9&5V96QO<&5D(&)Y('EO=2!T:&%T(&%D9', <VEG;FEF:6-A;G0 86YD M('!R:6UA<GD 9G5N8W1I;VYA;&ET>2!T;PT*=&AE(%)E9&ES=')I8G5T86)L M97, *)-!<'!L:6-A=&EO;I0I.R H8BDF;F)S<#MT:&4 4F5D:7-T<FEB=71A M($UI8W)O<V]F="!/<&5R871I;F< 4WES=&5M(%!R;V1U8W0[("AC*29N8G-P M.WEO=7(-"D%P<&QI8V%T:6]N('=I;&P :6YV;VME('1H92!3;V9T=V%R92!O M;FQY(#PO<W!A;CX\<W!A;B!S='EL93TG9F]N="UF86UI;'DZ(D)O;VL 06YT M:7%U82(G/G9I80T*:6YT97)F86-E<R!D97-C<FEB960 :6X =&AE(&1O8W5M M96YT871I;VX 86-C;VUP86YY:6YG('1H92!3;V9T=V%R93L\+W-P86X^/'-P M86X <W1Y;&4])V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SX *&0I)FYB M86EN:6YG('1H92!2961I<W1R:6)U=&%B;&5S(&]N;'D <'5R<W5A;G0 =&\ M86X 96YD+75S97( ;&EC96YS90T*86=R965M96YT("AW:&EC:"!M87D 8F4 M8G)E86LM=&AE+7-E86PL(&-L:6-K+7=R87 ;W( <VEG;F5D*2!W:71H('1E M:6X =&AI<R!%54Q!.R H92DF;F)S<#MY M;W-O9G22<R!N86UE+"!L;V=O+"!O<B!T<F%D96UA<FMS('1O(&UA<FME="!Y M;W5R($%P<&QI8V%T:6]N.R H9BDF;F)S<#MY;W4 =VEL; T*:6YC;'5D92!A M('9A;&ED(&-O<'ER:6=H="!N;W1I8V4 ;VX >6]U<B!!<'!L:6-A=&EO;B!S M=69F:6-I96YT('1O('!R;W1E8W0-"DUI8W)O<V]F=))S(&-O<'ER:6=H="!I M;B!T:&4 4V]F='=A<F4[("AG*29N8G-P.WEO=2!W:6QL(&YO="!R96UO=F4 M;W( ;V)S8W5R90T*86YY(&-O<'ER:6=H="P =')A9&5M87)K(&]R('!A=&5N M="!N;W1I8V5S('1H870 87!P96%R(&]N(&]R(&EN('1H92!3;V9T=V%R92!A M<PT*9&5L:79E<F5D('1O('EO=3L *& I)FYB<W [>6]U('=I;&P :6YD96UN M;2!A;F0 86=A:6YS="!A;GD 8VQA:6US(&]R(&QA=W-U:71S+"!I;F-L=61I M;F< 871T;W)N97ESDB!A;F0-"F5X<&5R='.2(&9E97,L('1H870 87)I<V4 M;W( <F5S=6QT(&9R;VT =&AE('5S92!O<B!D:7-T<FEB=71I;VX ;V8 >6]U M< T*07!P;&EC871I;VX[(&%N9" H:2DF;F)S<#MY;W4 =VEL;"!O=&AE<G=I M;6%Y(&YO="!P97)M:70 9G5R=&AE<B!D:7-T<FEB=71I;VX ;V8 4F5D:7-T M<FEB=71A8FQE<R!B>2!Y;W5R(&5N9"!U<V5R<PT*97AC97!T('1H870 >6]U M(&UA>2!P97)M:70 9G5R=&AE<B!R961I<W1R:6)U=&EO;B!O9B!2961I<W1R M:6)U=&%B;&5S(&)Y('EO=7(-"F1I<W1R:6)U=&]R<R!T;R!E;F0 =7-E<G, M:68 >6]U<B!D:7-T<FEB=71O<G, ;VYL>2!D:7-T<FEB=71E('1H90T*4F5D M:7-T<FEB=71A8FQE<R!I;B!C;VYJ=6YC=&EO;B!W:71H(&%N9"!A<R!P87)T M(&]F('EO=7( 07!P;&EC871I;VX ;W(-"D%P<&QI8V%T:6]N<RP >6]U(&-O M;7!L>2!W:71H(&%L;"!O=&AE<B!T97)M<R!O9B!T:&ES($553$$L(&%N9"!Y M<R!O9B!T:&ES($553$$ =&AA="!A<F4 87!P;&EC86)L92!T;PT*>6]U+J M/"]S<&%N/CPO<#X-" D)"3QP(&-L87-S/2)-<V].;W)M86PB('-T>6QE/2=M M87)G:6XM8F]T=&]M.C,N,'!T.W1E>'0M:6YD96YT.BXU:6XG/CQS<&%N('-T M>6QE/2=F;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,RXRH*" H*" (#QB M/CQI/E)E;F%M:6YG( T*"0D)"0D)"4U&0RP 051,(&]R($-25',\+VD^/"]B M=71I;F< =&AE;2!O<B!A;GD ;6]D:69I8V%T:6]N<R!T;R!T:&5M+J /"]S M<&%N/CPO<#X-" D)"3QP(&-L87-S/2)-<V].;W)M86PB('-T>6QE/2=M87)G M:6XM8F]T=&]M.C,N,'!T.W1E>'0M:6YD96YT.BXU:6XG/CQS<&%N('-T>6QE M/2=F;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,RXSH*" H*" (#QB/CQI M;GD 4F5D:7-T<FEB=71A8FQE($-O9&4 :&%V:6YG(&$ 9FEL96YA;64 97AT M96YS:6]N(&]F("YL:6(L('EO=2!M87D-"F1I<W1R:6)U=&4 ;VYL>2!T:&4 M<F5S=6QT<R!O9B!R=6YN:6YG('-U8V 4F5D:7-T<FEB=71A8FQE($-O9&4 M<&%N/CPO<#X-" D)"3QP(&-L87-S/2)-<V].;W)M86PB('-T>6QE/2=M87)G M:6XM8F]T=&]M.C,N,'!T.W1E>'0M:6YD96YT.BXU:6XG/CQS<&%N('-T>6QE M/2=F;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,RXTH*" H*" (#QE;3X\ M3F]T:6-E(&9O<B!7:6YD;W=S($UE9&EA(%1E8VAN;VQO9VEE<SPO<W!A;CX\ M:6YC;'5D92!A;GD 4F5D:7-T<FEB=71A8FQE<R!F<F]M('1H92!7:6YD;W=S M(#QS<&%N('-T>6QE/2=C;VQO<CIB;&%C:R<^365D:6$ 4&QA>65R(%-$2RP M5VEN9&]W<R!-961I82!397)V:6-E<R!31$LL(%=I;F1O=W, 365D:6$-"D5N M8V]D97( 4T1++"!O<B!7:6YD;W=S($UE9&EA(%-O9G1W87)E($1E=F5L;W!M M96YT($MI=" H:6YC;'5D:6YG(&)U="!N;W0-"FQI;6ET960 =&\L('1H929N M8G-P.U=I;F1O=W, 365D:6$ 1F]R;6%T(%-$2RD <&]R=&EO;G, ;V8 =&AE M<'!L:6-A=&EO;I)S($AE;' M06)O=70 8F]X("AO<B!I9B!T:&5R92!I<R!N M;R!S=6-H(&)O>"P-"G1H96X :6X 86YO=&AE<B!L;V-A=&EO;B!T:&%T(&5N M;W1I8V4 <W1A=&EN9R!T:&4 9F]L;&]W:6YG.J DU!O<G1I;VYS('5T:6QI M>F4 36EC<F]S;V9T(%=I;F1O=W, 365D:6$-"E1E8VAN;VQO9VEE<RZ ($-O M($%L;"!2:6=H=',-"E)E<V5R=F5D+I2 (#PO M;&%S<STB37-O3F]R;6%L(B!S='EL93TG;6%R9VEN+6)O='1O;3HS+C!P=#MT M97AT+6EN9&5N=#HN-6EN)SX\<W!A;B!S='EL93TG9F]N="UF86UI;'DZ(D)O M;VL 06YT:7%U82(G/C,N-:" H*" H" \8CX\:3Y.;R -" D)"0D)"0E!;'1E M<F%T:6]N('1O(%-E='5P(%!R;V=R86US+CPO:3X\+V(^H"!)9B!A;GD 4F5D M:7-T<FEB=71A8FQE<R!I;B!T:&4 4V]F='=A<F4 87, 9&5L:79E<F5D('1O M('EO=0T*87)E(&-O;G1A:6YE9"!I;B!A('-E<&%R871E('-E='5P('!R;V=R M86TL('1H96X >6]U(&UA>2!O;FQY(&1I<W1R:6)U=&4 =&AO<V4-"E)E9&ES M=')I8G5T86)L97, 87, <&%R="!O9B!T:&%T('-E='5P('!R;V=R86TL('=I M;6]V86P ;V8 86YY(&]F(&ET<R!C;VUP;VYE;G1S+J /"]S<&%N/CPO<#X- M" D)"3QP(&-L87-S/2)-<V].;W)M86PB('-T>6QE/2=M87)G:6XM8F]T=&]M M.C,N,'!T.W1E>'0M:6YD96YT.BXU:6XG/CQS<&%N('-T>6QE/2=F;VYT+69A M;6EL>3HB0F]O:R!!;G1I<75A(B<^,RXVH*" H*" (#QB/CQI/E!R97)E;&5A M8V]N=&%I;B!P<F5R96QE87-E(&-O9&4 =&AA="!M:6=H="!N;W0 ;W!E<F%T M92!C;W)R96-T;'DL(&ES(&YO= T*870 =&AE(&QE=F5L(&]F('!E<F9O<FUA M;F-E(&%N9"!C;VUP871I8FEL:71Y(&]F('1H92!F:6YA;"P 9V5N97)A;&QY M(&%V86EL86)L90T*<')O9'5C="!O9F9E<FEN9RP 86YD(&UI9VAT(&)E('-U M8G-T86YT:6%L;'D ;6]D:69I960 <')I;W( =&\ <VAI<&UE;G0 ;V8 =&AA M= T*;V9F97)I;F<NH"!-:6-R;W-O9G0 :7, ;F]T(&]B;&EG871E9"!T;R!M M92!C;VUM97)C:6%L;'D 879A:6QA8FQE+J 66]U<B!L:6-E;G-E('5N9&5R M<R!I9&5N=&EF:65D(&EN('1H92!D;V-U;65N=&%T:6]N(&%S('!R97)E;&5A M('5N9&5R(&$ <VEM:6QA<B!D97-I9VYA=&EO;B!I;F1I8V%T:6YG(&-O9&4 M=&AA= T*:7, ;F]T(&EN=&5N9&5D(&9O<B!C;VUM97)C:6%L(&1I<W1R:6)U M;F1I=&EO;F5D('5P;VX >6]U<B!M87)K:6YG('1H92!V97)S:6]N(&]F('EO M=7( 07!P;&EC871I;VX 8V]N=&%I;FEN9R!T:&4 4')E<F5L96%S90T*0V]D M92!A<R"30D5402R4()-04D4M4D5,14%3190 ;W( ;W1H97( <F5A<V]N86)L M<F]S;V9TDG, <'5B;&EC;'D-"F%N;F]U;F-E9"!C;VUM96YC96UE;G0 ;V8 M=&AE(&-O;6UE<F-I86P 879A:6QA8FEL:71Y(&]F('1H92!-:6-R;W-O9G0- M"D]P97)A=&EN9R!3>7-T96T 4')O9'5C="!F;W( =VAI8V >6]U<B!!<'!L M:6-A=&EO;B!I<R!D979E;&]P960NH" \+W-P86X^/"]P/ T*"0D)/' 8VQA M<W,](DUS;TYO<FUA;"( <W1Y;&4])VUA<F=I;BUB;W1T;VTZ,RXP<'0[=&5X M="UI;F1E;G0Z+C5I;B<^/'-P86X <W1Y;&4])V9O;G0M9F%M:6QY.B)";V]K M($%N=&EQ=6$B)SXS+C> H*" H* /&(^/&D^261E;G1I9FEE9" -" D)"0D) M"0E3;V9T=V%R92X\+VD^(#PO8CZ 268-"GEO=2!U<V4 =&AE(%)E9&ES=')I M8G5T86)L97,L('1H96X :6X 861D:71I;VX =&\ >6]U<B!C;VUP;&EA;F-E M;VQL;W=I;F< 86QS;R!A<'!L:65S+J 66]U<B!L:6-E;G-E(')I9VAT<R!T M;R!2961I<W1R:6)U=&%B;&5S(&%R92!C;VYD:71I;VYE9 T*;VX >6]U<B H M82DF;F)S<#MN;W0 :6YC;W)P;W)A=&EN9R!)9&5N=&EF:65D(%-O9G1W87)E M=&AE(%)E9&ES=')I8G5T86)L97,[H" H8BDF;F)S<#MN;W0 9&ES=')I8G5T M9R!)9&5N=&EF:65D(%-O9G1W87)E(&EN('1H92!D979E;&]P;65N="!O9B!A M(&1E<FEV871I=F4 =V]R:R!O9B!3;W5R8V4-"D-O9&4NH""3261E;G1I9FEE M9"!3;V9T=V%R990 ;65A;G, <V]F='=A<F4 =&AA="!I<R!L:6-E;G-E9"!P M=7)S=6%N="!T;R!T97)M<PT*=&AA="!D:7)E8W1L>2!O<B!I;F1I<F5C=&QY M(&-R96%T92P ;W( <'5R<&]R="!T;R!C<F5A=&4L(&]B;&EG871I;VYS(&9O M< T*36EC<F]S;V9T('=I=& <F5S<&5C="!T;R!T:&4 4F5D:7-T<FEB=71A M8FQE<R!O<B!G<F%N="P ;W( <'5R<&]R="!T;R!G<F%N="P-"G1O(&%N>2!T M:&ER9"!P87)T>2!A;GD <FEG:'1S(&]R(&EM;75N:71I97, =6YD97( 36EC M>2!R:6=H=', :6X =&AE(%)E9&ES=')I8G5T86)L97,NH"!)9&5N=&EF:65D M<V]F='=A<F4 =&AA="!R97%U:7)E<R!A<R!A(&-O;F1I=&EO;B!O9B!I=',- M"G5S92P ;6]D:69I8V%T:6]N(&%N9"]O<B!D:7-T<FEB=71I;VX =&AA="!A M(&9R;VT ;W( 9&ES=')I8G5T960 =VET:"!S=6-H('-O9G1W87)E(&UU<W0 M86QS;R!B92!D:7-C;&]S960 ;W(-"F1I<W1R:6)U=&5D(&EN('-O=7)C92!C M;V1E(&9O<FTL(&QI8V5N<V5D(&9O<B!T:&4 <'5R<&]S92!O9B!M86MI;F< M9&5R:79A=&EV90T*=V]R:W,L(&]R(')E9&ES=')I8G5T86)L92!A="!N;R!C M:&%R9V4NH" \+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](DUS;TYO<FUA;"( M<W1Y;&4])VUA<F=I;BUB;W1T;VTZ,RXP<'0G/CQB/CQS<&%N('-T>6QE/2=F M;VYT+69A;6EL>3H-"B)";V]K($%N=&EQ=6$B.W1E>'0M=')A;G-F;W)M.G5P M/CQS<&%N('-T>6QE/2=F;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^+CPO M<W!A;CX\<W!A;B!S='EL93TG9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U82(G M/J -"D%S(&$ :VET(&]F(&1E=F5L;W!M96YT('1O;VQS(&%N9"!O=&AE<B!- M:6-R;W-O9G0 <V]F='=A<F4 <')O9W)A;7, *&5A8V <W5C: T*=&]O;"!O M87)E(&UA>2!C;VYT86EN(&]N92!O<B!M;W)E($-O;7!O;F5N=',-"F9O<B!W M:&EC:" \<W!A;B!S='EL93TG;&5T=&5R+7-P86-I;F<Z+2XQ<'0G/F$ <V5P M;G0 155,090I(&UA>2!A<'!E87( =7!O;B!I;G-T86QL871I;VX ;V8 =&AE M(&%P<&QI8V%B;&4 0V]M<&]N96YT+J -"DEN('1H92!E=F5N="!O9B!I;F-O M;"!C;VYT<F]L(&%S('1O('1H92!A<'!L:6-A8FQE($-O;7!O;F5N="Z (#PO M<W!A;CX\+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](C-C3G5M8F5R960B('-T M>6QE/2=M87)G:6XM=&]P.C!I;CMM87)G:6XM<FEG:'0Z,&EN.VUA<F=I;BUB M.VQI;F4M:&5I9VAT.FYO<FUA;"<^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ M93H-"C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^-2X\+W-P M86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.PT*9F]N="UF M86UI;'DZ(D)O;VL 06YT:7%U82(G/J" H*" H*" (#QB/E)%4T525D%424]. M<R!L:6-E;G-E9"P ;F]T('-O;&0NH"!-:6-R;W-O9G0 <F5S97)V97, 86QL M($553$$NH"!4:&4 4V]F='=A<F4 :7, <')O=&5C=&5D(&)Y(&-O<'ER:6=H M="!A;F0 ;W1H97(-"FEN=&5L;&5C='5A;"!P<F]P97)T>2!L87=S(&%N9"!T M<F5A=&EE<RX 36EC<F]S;V9T(&]R(&ET<R!S=7!P;&EE<G, ;W=N('1H90T* M=&ET;&4L(&-O<'ER:6=H="P 86YD(&]T:&5R(&EN=&5L;&5C='5A;"!P<F]P M97)T>2!R:6=H=', :6X =&AE(%-O9G1W87)E+J /"]S<&%N/CPO<#X-" D) M"3QP(&-L87-S/2(S:4YU;6)E<F5D,FYD;&5V96PB('-T>6QE/2=M87)G:6XM M=#MM87)G:6XM;&5F=#HP:6X[=&5X="UI;F1E;G0Z,&EN.VQI;F4M:&5I9VAT M.FYO<FUA;"<^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N M="UF86UI;'DZ(D)O;VL 06YT:7%U82(G/C8N/"]S<&%N/CPO8CX\<W!A;B!S M='EL93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I M4E-%($5.1TE.145224Y'+"!$14-/35!)3$%424].+"!!3D0 1$E305-314U" M+"!D96-O;7!I;&4L(&]R(&1I<V%S<V5M8FQE('1H92!3;V9T=V%R92P 97AC M"0D\<"!C;&%S<STB,V-.=6UB97)E9"( <W1Y;&4])VUA<F=I;CHP:6X[;6%R M<W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT M14Y404P 3U( 0T]-34520TE!3"!(3U-424Y'+B" /"]S<&%N/CPO8CX\<W!A M;B!S='EL93TG9F]N="US:7IE.C$R+C!P=#L-"F9O;G0M9F%M:6QY.B)";V]K M($%N=&EQ=6$B)SY9;W4 ;6%Y(&YO="!R96YT+"!L96%S92P ;&5N9"!O<B!P M<F]V:61E(&-O;6UE<F-I86P-"FAO<W1I;F< <V5R=FEC97, =VET:"!T:&4 M4V]F='=A<F4N/"]S<&%N/CPO<#X-" D)"3QP(&-L87-S/2(S:4YU;6)E<F5D M,FYD;&5V96PB('-T>6QE/2=M87)G:6XM=&]P.C!I;CMM87)G:6XM<FEG:'0Z M="UI;F1E;G0Z,&EN.VQI;F4M:&5I9VAT.FYO<FUA;"<^/&(^/'-P86X <W1Y M;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U M82(G/C NH*" H*" H* /"]S<&%N/CPO8CX\8CX\<W!A;B!S='EL93TG9F]N M="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^0T]. M4T5.5"!43R!54T4 3T8 1$%402X\+W-P86X^/"]B/CQB/CQS<&%N('-T>6QE M/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B M)SX\+W-P86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O M;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SY9;W4 86=R964 =&AA="!-:6-R M;W-O9G0-"F%N9"!I=', 869F:6QI871E<R!M87D 8V]L;&5C="!A;F0 =7-E M:&4 <')O9'5C="!S=7!P;W)T('-E<G9I8V5S('!R;W9I9&5D('1O('EO=2P M:68 86YY+"!R96QA=&5D('1O('1H90T*4V]F='=A<F4NH"!-:6-R;W-O9G0 M;6%Y('5S92!T:&ES(&EN9F]R;6%T:6]N('-O;&5L>2!T;R!I;7!R;W9E(&]U M<B!P<F]D=6-T<R!O< T*=&\ <')O=FED92!C=7-T;VUI>F5D('-E<G9I8V5S M(&]R('1E8VAN;VQO9VEE<R!T;R!Y;W4 86YD('=I;&P ;F]T(&1I<V-L;W-E M:61E;G1I9FEE<R!Y;W4NH" \+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](C-C M3G5M8F5R960B('-T>6QE/2=M87)G:6XM;&5F=#HP:6X[=&5X="UI;F1E;G0Z M,&EN)SX\8CX\<W!A;B!S='EL93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A M;6EL>3HB0F]O:R!!;G1I<75A(B<^.2Z H*" H*" H"!,24Y+4R!43R!42$E2 M1"U005)460T*4TE415,NH" \+W-P86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT M+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SY9;W4- M"FUA>2!L:6YK('1O('1H:7)D+7!A<G1Y('-I=&5S('1H<F]U9V =&AE('5S M92!O9B!T:&4 4V]F='=A<F4NH"!4:&4 =&AI<F0M<&%R='D-"G-I=&5S(&%R M92!N;W0 =6YD97( =&AE(&-O;G1R;VP ;V8 36EC<F]S;V9T+"!A;F0 36EC M<F]S;V9T(&ES(&YO="!R97-P;VYS:6)L90T*9F]R('1H92!C;VYT96YT<R!O M9B!A;GD =&AI<F0M<&%R='D <VET97,L(&%N>2!L:6YK<R!C;VYT86EN960 M:6X =&AI<F0M<&%R='D-"G-I=&5S+"!O<B!A;GD 8VAA;F=E<R!O<B!U<&1A M=&5S('1O('1H:7)D+7!A<G1Y('-I=&5S+J 36EC<F]S;V9T(&ES(&YO= T* M<F5S<&]N<VEB;&4 9F]R('=E8BUC87-T:6YG(&]R(&%N>2!O=&AE<B!F;W)M M(&]F('1R86YS;6ES<VEO;B!R96-E:79E9"!F<F]M(&%N>0T*=&AI<F0M<&%R M='D <VET97,NH"!-:6-R;W-O9G0 :7, <')O=FED:6YG('1H97-E(&QI;FMS M('1O('1H:7)D+7!A<G1Y('-I=&5S('1O('EO=0T*;VYL>2!A<R!A(&-O;G9E M;FEE;F-E+"!A;F0 =&AE(&EN8VQU<VEO;B!O9B!A;GD ;&EN:R!D;V5S(&YO M="!I;7!L>2!A; T*96YD;W)S96UE;G0 8GD 36EC<F]S;V9T(&]F('1H92!T M+7)I9VAT.C!I;CMM87)G:6XM8F]T=&]M. T*,RXP<'0[;6%R9VEN+6QE9G0Z M,&EN.W1E>'0M:6YD96YT.C!I;CML:6YE+6AE:6=H=#IN;W)M86PG/CQB/CQS M<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY.B)";V]K M($%N=&EQ=6$B)SXQ,"Z H*" H* /"]S<&%N/CPO8CX\8CX\<W!A;B!S='EL M93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A M/"]B/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY M.B)";V]K($%N=&EQ=6$B)SY4:&ES($553$$-"F%P<&QI97, =&\ =7!D871E M<RP <W5P<&QE;65N=',L(&%D9"UO;B!C;VUP;VYE;G1S(&]R($EN=&5R;F5T M:&%T($UI8W)O<V]F="!M87D <')O=FED92!T;R!Y;W4 ;W( ;6%K92!A=F%I M;&%B;&4-"G1O('EO=2!A9G1E<B!T:&4 9&%T92!Y;W4 ;V)T86EN('EO=7( M:6YI=&EA;"!C;W!Y(&]F('1H92!3;V9T=V%R92P =6YL97-S($UI8W)O<V]F M= T*<')O=FED97, ;W1H97( =&5R;7, 86QO;F< =VET:"!T:&4 =7!D871E M+"!S=7!P;&5M96YT+"!A9&0M;VX 8V]M<&]N96YT+"!O< T*26YT97)N970M M8F%S960 <V5R=FEC97, 8V]M<&]N96YT+J 36EC<F]S;V9T(')E<V5R=F5S M('1H92!R:6=H="!T;R!D:7-C;VYT:6YU90T*86YY($EN=&5R;F5T+6)A<V5D M('-E<G9I8V5S('!R;W9I9&5D('1O('EO=2!O<B!M861E(&%V86EL86)L92!T M;R!Y;W4 =&AR;W5G: T*=&AE('5S92!O9B!T:&4 4V]F='=A<F4NH" \+W-P M86X^/"]P/ T*"0D)/' 8VQA<W,](C-I3G5M8F5R960R;F1L979E;"( <W1Y M;&4])VUA<F=I;BUT;W Z,&EN.VUA<F=I;BUR:6=H=#HP:6X[;6%R9VEN+6)O M='1O;3H-"C,N,'!T.VUA<F=I;BUL969T.C!I;CMT97AT+6EN9&5N=#HP:6X[ M;&EN92UH96EG:'0Z;F]R;6%L)SX\8CX\<W!A;B!S='EL93TG9F]N="US:7IE M.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,3$NH*" H*" M(#PO<W!A;CX\+V(^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[ M3E,\+W-P86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O M;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SXNH" \<W!A;B!S='EL93TG;&%Y M;W5T+6=R:60M;6]D93H-"FQI;F4G/EEO=2!A8VMN;W=L961G92!T:&%T('1H M92!3;V9T=V%R92!I<R!S=6)J96-T('1O(%4N4RX 97AP;W)T(&IU<FES9&EC M=&EO;BZ (%EO=2!A9W)E92!T;R!C;VUP;'D =VET:"!A;&P 87!P;&EC86)L M92!I;G1E<FYA=&EO;F%L(&%N9 T*;F%T:6]N86P ;&%W<R!T:&%T(&%P<&QY M('1O('1H92!3;V9T=V%R92P :6YC;'5D:6YG('1H92!5+E,N($5X<&]R= T* M061M:6YI<W1R871I;VX 4F5G=6QA=&EO;G,L(&%S('=E;&P 87, 96YD+75S M97(L(&5N9"UU<V4L(&%N9"!D97-T:6YA=&EO; T*<F5S=')I8W1I;VYS(&ES M<W5E9"!B>2!5+E,N(&%N9"!O=&AE<B!G;W9E<FYM96YT<RZ ($9O<B!A9&1I M<F]S;V9T+F-O;2]E>'!O<G1I;F<O)F=T.SPO=3XN/"]S<&%N/CPO<W!A;CX\ M;6%R9VEN+71O<#HP:6X[;6%R9VEN+7)I9VAT.C!I;CMM87)G:6XM8F]T=&]M M. T*,RXP<'0[;6%R9VEN+6QE9G0Z,&EN.W1E>'0M:6YD96YT.C!I;CML:6YE M+6AE:6=H=#IN;W)M86PG/CQB/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N M,'!T.V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SXQ,BZ H*" H* 4T]& M5%=!4D4 5%)!3E-&15(\:3XN/"]I/CPO<W!A;CX\+V(^/'-P86X <W1Y;&4] M)V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U82(G M/J 5&AE(&EN:71I86P =7-E<B!O9B!T:&4-"E-O9G1W87)E(&UA>2!M86ME M(&$ ;VYE+71I;64 <&5R;6%N96YT('1R86YS9F5R(&]F('1H:7, 155,02!A M;F0 4V]F='=A<F4 =&\-"F%N;W1H97( 96YD('5S97(L('!R;W9I9&5D('1H M92!I;FET:6%L('5S97( <F5T86EN<R!N;R!C;W!I97, ;V8 =&AE(%-O9G1W M87)E+J -"E1H:7, =')A;G-F97( ;75S="!I;F-L=61E(&%L;"!O9B!T:&4 M4V]F='=A<F4 *&EN8VQU9&EN9R!A;&P 8V]M<&]N96YT('!A<G1S+ T*=&AE M(&UE9&EA(&%N9"!P<FEN=&5D(&UA=&5R:6%L<RP 86YY('5P9W)A9&5S+"!T M92!O9B!!=71H96YT:6-I='DI+J 5&AE('1R86YS9F5R(&UA>2!N;W0 8F4 MH"!0<FEO<B!T;R!T:&4 =')A;G-F97(L('1H92!E;F0 =7-E<B!R96-E:79I M97)M<RX\+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](C-I3G5M8F5R960R;F1L M979E;"( <W1Y;&4])VUA<F=I;BUT;W Z,&EN.VUA<F=I;BUR:6=H=#HP:6X[ M;6%R9VEN+6)O='1O;3H-"C,N,'!T.VUA<F=I;BUL969T.C!I;CMT97AT+6EN M9&5N=#HP:6X[;&EN92UH96EG:'0Z;F]R;6%L)SX\8CX\<W!A;B!S='EL93TG M9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^ M,3,NH*" H*" (%1%4DU)3D%424].+CPO<W!A;CX\+V(^/'-P86X <W1Y;&4] M)V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U82(G M8W)O<V]F="!M87D =&5R;6EN871E('1H:7, 155,02!I9B!Y;W4 9F%I;"!T M;R!C;VUP;'D =VET:"!T:&4-"G1E<FUS(&%N9"!C;VYD:71I;VYS(&]F('1H M:7, 155,02X H$EN('-U8V 979E;G0L('EO=2!M=7-T(&1E<W1R;WD 86QL M(&-O<&EE<PT*;V8 =&AE(%-O9G1W87)E(&%N9"!A;&P ;V8 :71S(&-O;7!O M;F5N="!P87)T<RX\+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](C-C3G5M8F5R M960B('-T>6QE/2=M87)G:6XM;&5F=#HP:6X[=&5X="UI;F1E;G0Z,&EN)SX\ M8CX\<W!A;B!S='EL93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB M0F]O:R!!;G1I<75A(B<^,30NH*" H*" ($1)4T-,04E-15( 3T8-"E=!4E)! M3E1)15,N(#QS<&%N('-T>6QE/2=T97AT+71R86YS9F]R;3IU<'!E<F-A<V4G M/J!T;R!T:&4 ;6%X:6UU;2!E>'1E;G0-"G!E<FUI='1E9"!B>2!A<'!L:6-A M8FQE(&QA=RP 36EC<F]S;V9T(&%N9"!I=', <W5P<&QI97)S('!R;W9I9&4 M=&AE(%-O9G1W87)E/"]S<&%N/CPO<W!A;CX\+V(^/'-P86X <W1Y;&4])V9O M;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U82([=&5X M="UT<F%N<V9O<FTZ=7!P97)C87-E)SX-" D)"0D)/&(^86YD('-U<'!O<G0 M<V5R=FEC97, *&EF(&%N>2D /&D^05, 25, 04Y$(%=)5$ 04Q,($9!54Q4 M=V%R<F%N=&EE<R!A;F0 8V]N9&ET:6]N<RP =VAE=&AE<B!E>'!R97-S+"!I M;7!L:65D(&]R( T*"0D)"0D)<W1A='5T;W)Y+"!I;F-L=61I;F<L(&)U="!N M;W0 ;&EM:71E9"!T;RP 86YY("AI9B!A;GDI(&EM<&QI960 =V%R<F%N=&EE M:6QI='DL(&]F(&9I=&YE<W, 9F]R(&$ <&%R=&EC=6QA<B!P=7)P;W-E+" - M" D)"0D)"6]F(')E;&EA8FEL:71Y(&]R(&%V86EL86)I;&ET>2P ;V8 86-C M"0ER97-U;'1S+"!O9B!W;W)K;6%N;&EK92!E9F9O<G0L(&]F(&QA8VL ;V8 M;&P =VET:"!R96=A<F0 =&\ =&AE(%-O9G1W87)E(&%N9"!T:&4 <')O=FES M:6]N(&]F(&]R(&9A:6QU<F4 =&\ <')O=FED92 -" D)"0D)"7-U<'!O<G0 M;W( ;W1H97( <V5R=FEC97,L(&EN9F]R;6%T:6]N+"!S;V9T=V%R92P 86YD M(')E;&%T960 8V]N=&5N="!T:')O=6=H( T*"0D)"0D)=&AE(%-O9G1W87)E M(&]R(&]T:&5R=VES92!A<FES:6YG(&]U="!O9B!T:&4 =7-E(&]F('1H92!3 M;V9T=V%R92X\+V(^/"]S<&%N/CQB/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z M,3(N,'!T.V9O;G0M9F%M:6QY.B)";V]K($%N=&EQ=6$B)SZ ($%,4T\L(%1( M2454($5.2D]9345.5"P 455)150 4$]34T534TE/3BP-"D-/4E)%4U!/3D1% M3D-%(%1/($1%4T-225!424].+"!/4B!.3TXM24Y&4DE.1T5-14Y4/'-P86X M<W1Y;&4])W1E>'0M=')A;G-F;W)M. T*=7!P97)C87-E)SX 5TE42"!214=! M4D0 5$\ 5$A%(%-/1E1705)%/"]S<&%N/BX\+W-P86X^/"]B/CPO<#X-" D) M"3QP(&-L87-S/2(S8TYU;6)E<F5D(B!S='EL93TG;6%R9VEN+6QE9G0Z,&EN M.W1E>'0M:6YD96YT.C!I;B<^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ M,BXP<'0[9F]N="UF86UI;'DZ(D)O;VL 06YT:7%U82(G/C$U+J" H*" H"!% M6$-,55-)3TX 3T8-"DE.0TE$14Y404PL($-/3E-%455%3E1)04P 04Y$($-% M4E1!24X 3U1(15( 1$%-04=%4RZ (#QS<&%N('-T>6QE/2=T97AT+71R86YS M9F]R;3H-"G5P<&5R8V%S92<^5&\ =&AE(&UA>&EM=6T 97AT96YT('!E<FUI M='1E9"!B>2!A<'!L:6-A8FQE(&QA=RP :6X ;F\ 979E;G0 <VAA;&P-"DUI M8W)O<V]F="!O<B!I=', <W5P<&QI97)S(&)E(&QI86)L92!F;W( 86YY('-P M96-I86PL(&EN8VED96YT86PL('!U;FET:79E+ T*:6YD:7)E8W0L(&]R(&-O M;G-E<75E;G1I86P 9&%M86=E<R!W:&%T<V]E=F5R("AI;F-L=61I;F<L(&)U M="!N;W0 ;&EM:71E9"!T;RP-"F1A;6%G97, 9F]R(&QO<W, ;V8 <')O9FET M<R!O<B!C;VYF:61E;G1I86P ;W( ;W1H97( :6YF;W)M871I;VX\+W-P86X^ M+" \<W!A;B!S='EL93TG=&5X="UT<F%N<V9O<FTZ=7!P97)C87-E)SYF;W( M8G5S:6YE<W, :6YT97)R=7!T:6]N+"!F;W( <&5R<V]N86P-"FEN:G5R>2P M9F]R(&QO<W, ;V8 <')I=F%C>2P 9F]R(&9A:6QU<F4 =&\ ;65E="!A;GD M9'5T>2!I;F-L=61I;F< ;V8 9V]O9 T*9F%I=& ;W( ;V8 <F5A<V]N86)L M92!C87)E+"!F;W( ;F5G;&EG96YC92P 86YD/"]S<&%N/B \<W!A;B!S='EL M<&5C=6YI87)Y(&]R(&]T:&5R(&QO<W, =VAA='-O979E<BD 87)I<VEN9R!O M=70 ;V8 ;W(-"FEN(&%N>2!W87D <F5L871E9"!T;R!T:&4 =7-E(&]F(&]R M(&EN86)I;&ET>2!T;R!U<V4 =&AE(%-/1E1705)%+"!T:&4-"G!R;W9I<VEO M;B!O9B!O<B!F86EL=7)E('1O('!R;W9I9&4 4W5P<&]R="!/4B!/5$A%4B!3 M3TY414Y4('1H<F]U9V =&AE('-O9G1W87)E(&]R(&]T:&5R=VES92!A<FES M:6YG(&]U="!O9 T*=&AE('5S92!O9B!T:&4 <V]F='=A<F4L(&]R(&]T:&5R M=VES92!U;F1E<B!O<B!I;B!C;VYN96-T:6]N('=I=& 86YY('!R;W9I<VEO M; T*;V8 =&AI<R!%54Q!+"!E=F5N(&EN('1H92!E=F5N="!O9B!T:&4 9F%U M;'0L('1O<G0 *&EN8VQU9&EN9R!N96=L:6=E;F-E*2P-"FUI<W)E<')E<V5N M=&%T:6]N+"!S=')I8W0 ;&EA8FEL:71Y+"!B<F5A8V ;V8 8V]N=')A8W0 M<'!L:65R+"!A;F0 979E;B!I9B!-:6-R;W-O9G0 ;W( 86YY('-U<'!L:65R M(&1A;6%G97,N(#PO<W!A;CX\+W-P86X^/"]B/CPO<#X-" D)"3QP(&-L87-S M/2(S8TYU;6)E<F5D(B!S='EL93TG;6%R9VEN+6QE9G0Z,&EN.W1E>'0M:6YD M96YT.C!I;B<^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N M="UF86UI;'DZ(D)O;VL 06YT:7%U82(G/C$V+J" H*" H"!,24U)5$%424]. M9&%M86=E<R!T:&%T('EO=2!M:6=H="!I;F-U<B!F;W( 86YY(')E87-O;B!W M:&%T<V]E=F5R("AI;F-L=61I;F<L('=I=&AO=70-"FQI;6ET871I;VXL(&%L M;"!D86UA9V5S(')E9F5R96YC960 :&5R96EN(&%N9"!A;&P 9&ER96-T(&]R M(&=E;F5R86P 9&%M86=E<R!I; T*8V]N=')A8W0 ;W( 86YY=&AI;F< 96QS M92DL('1H92!E;G1I<F4 ;&EA8FEL:71Y(&]F($UI8W)O<V]F="!A;F0 86YY M(&]F(&ET<PT*<W5P<&QI97)S('5N9&5R(&%N>2!P<F]V:7-I;VX ;V8 =&AI M:&%L;"!B92!L:6UI=&5D('1O('1H92!G<F5A=&5R(&]F('1H92!A8W1U86P M9&%M86=E<R!Y;W4 :6YC=7( :6X <F5A<V]N86)L90T*<F5L:6%N8V4 ;VX M=&AE(%-O9G1W87)E('5P('1O('1H92!A;6]U;G0 86-T=6%L;'D <&%I9"!B M>2!Y;W4 9F]R('1H92!3;V9T=V%R93PO<W!A;CX\+W-P86X^/"]B/CQS<&%N M('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY.B)";V]K($%N M>'1E;G0 <&5R;6ET=&5D(&)Y( T*"0D)"0D)87!P;&EC86)L92!L87<L(&5V M96X :68 86YY(')E;65D>2!F86EL<R!I=', 97-S96YT:6%L('!U<G!O<V4N M;&4])VUA<F=I;BUT;W Z-BXP<'0[;6%R9VEN+7)I9VAT.C!I;CMM87)G:6XM M8F]T=&]M. T*,&EN.VUA<F=I;BUL969T.C!I;CMM87)G:6XM8F]T=&]M.BXP M:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^,3<NH*" MH*" (%4N4RX 1T]615).345.5"!,24-%3E-%(%))1TA44SPO<W!A;CX\+V(^ M/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI;'DZ(D)O M;VL 06YT:7%U82(G/BX-"J!!;&P 4V]F='=A<F4 <')O=FED960 =&\ =&AE M(%4N4RX 1V]V97)N;65N="!P=7)S=6%N="!T;R!S;VQI8VET871I;VYS(&ES M<W5E9 T*;VX ;W( 869T97( 1&5C96UB97( ,2P ,3DY-2P :7, <')O=FED M960 =VET:"!T:&4 8V]M;65R8VEA;"!L:6-E;G-E(')I9VAT<PT*86YD(')E M<W1R:6-T:6]N<R!D97-C<FEB960 96QS97=H97)E(&AE<F5I;BZ ($%L;"!3 M;V9T=V%R92!P<F]V:61E9"!T;R!T:&4 52Y3+ T*1V]V97)N;65N="!P=7)S M=6%N="!T;R!S;VQI8VET871I;VYS(&ES<W5E9"!P<FEO<B!T;R!$96-E;6)E M<B Q+" Q.3DU+"!I<PT*<')O=FED960 =VET:""34F5S=')I8W1E9"!2:6=H M5" Q.3 X*2P 87, 87!P;&EC86)L92X /"]S<&%N/CPO<#X-" D)"3QP(&-L M87-S/2(S8TYU;6)E<F5D(B!S='EL93TG;6%R9VEN+71O<#HV+C!P=#MM87)G M/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M:6QY.B)" M86X^/"]B/CQS<&%N('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M M:6QY.B)";V]K($%N=&EQ=6$B)SY)9B!Y;W4 86-Q=6ER960 =&AI<PT*4V]F M='=A<F4 :6X =&AE(%5N:71E9"!3=&%T97,L('1H:7, 155,02!I<R!G;W9E M<FYE9"!B>2!T:&4 ;&%W<R!O9B!T:&4 4W1A=&4-"F]F(%=A<VAI;F=T;VXN M;&5S<R!E>'!R97-S;'D-"G!R;VAI8FET960 8GD ;&]C86P ;&%W+"!T:&ES M($553$$ :7, 9V]V97)N960 8GD =&AE(&QA=W, :6X 9F]R8V4 :6X =&AE M="!O9B!A;GD 9&ES<'5T92!W:&EC:"!M87D 87)I<V4-"FAE<F5U;F1E<BP M>6]U(&-O;G-E;G0 =&\ =&AE(&IU<FES9&EC=&EO;B!O9B!T:&4 9F5D97)A M;"!A;F0 <')O=FEN8VEA;"!C;W5R=',-"G-I='1I;F< :6X 5&]R;VYT;RP M3VYT87)I;RX H$EF('EO=2!A8W%U:7)E9"!T:&ES(%-O9G1W87)E(&EN('1H M92!%=7)O<&5A; T*56YI;VXL($EC96QA;F0L($YO<G=A>2P ;W( 4W=I='IE M<FQA;F0L('1H96X ;&]C86P ;&%W(&%P<&QI97,NH"!)9B!Y;W4-"F%C<75I M<F5D('1H:7, 4V]F='=A<F4 :6X 86YY(&]T:&5R(&-O=6YT<GDL('1H96X M;&]C86P ;&%W(&UA>2!A<'!L>2X /"]S<&%N/CPO<#X-" D)"3QP(&-L87-S M/2(S8TYU;6)E<F5D(B!S='EL93TG;6%R9VEN+6QE9G0Z,&EN.W1E>'0M:6YD M96YT.C!I;B<^/&(^/'-P86X <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N M="UF86UI;'DZ(D)O;VL 06YT:7%U82(G/C$Y+J" H*" H"!%3E1)4D4 04=2 M145-14Y4.PT*4T5615)!0DE,2519+J /"]S<&%N/CPO8CX\<W!A;B!S='EL M93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A M(B<^5&AI<PT*155,02 H:6YC;'5D:6YG(&%N>2!A9&1E;F1U;2!O<B!A;65N M9&UE;G0 =&\ =&AI<R!%54Q!('=H:6-H(&ES(&EN8VQU9&5D('=I=& -"G1H M92!3;V9T=V%R92D :7, =&AE(&5N=&ER92!A9W)E96UE;G0 8F5T=V5E;B!Y M;W4 86YD($UI8W)O<V]F="!R96QA=&EN9R!T;R!T:&4-"E-O9G1W87)E(&%N M9"!T:&4 <W5P<&]R="!S97)V:6-E<R H:68 86YY*2!A;F0 :70 <W5P97)S M961E<R!A;&P <')I;W( ;W(-"F-O;G1E;7!O<F%N96]U<R!O<F%L(&]R('=R M:71T96X 8V]M;75N:6-A=&EO;G,L('!R;W!O<V%L<R!A;F0 <F5P<F5S96YT M;R!T:&4 97AT96YT('1H92!T97)M<R!O9B!A;GD 36EC<F]S;V9T('!O;&EC M="!W:71H('1H92!T97)M<R!O9B!T:&ES($553$$L('1H92!T97)M<R!O9B!T M:&ES($553$$ <VAA;&P-"F-O;G1R;VPNH"!)9B!A;GD <')O=FES:6]N(&]F M9F]R8V5A8FQE(&]R(&EL;&5G86PL('1H92!O=&AE<B!P<F]V:7-I;VYS('-H M/CPO<#X-" D)"3QP(&-L87-S/2(R849R96YC:%-U8FAE860B/CQB/CQS<&%N M(&QA;F<](D92(B!S='EL93TG9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL M>3H-"B)";V]K($%N=&EQ=6$B)SY3:2!V;W5S(&%V97H 86-Q=6ES('9O=')E M('!R;V1U:70 36EC<F]S;V9T(&%U($-!3D%$02P ;&$-"F=A<F%N=&EE(&QI M;6ETZ64 <W5I=F%N=&4 =F]U<R!C;VYC97)N929N8G-P.SH\+W-P86X^/"]B M/CPO<#X-" D)"3QP(&-L87-S/2(R849R96YC:%-U8FAE860B/CQA(&YA;64] M9F]N="US:7IE.C$R+C!P=#MF;VYT+69A;6EL>3HB0F]O:R!!;G1I<75A(B<^ M1,E.22!$12!'05)!3E1)15,N(*!,90T*3&]G:6-I96P 970 ;&5S('-E<G9I M8V5S(&1E('-O=71I96X =&5C:&YI<75E("AL92!C87, Z6-HZ6%N="D <V]N M4R!P87( 36EC<F]S;V9T(&5T('-E<R!F;W5R;FES<V5U<G,L(&QE<W%U96QS M86YT:65S(&5T(&-O;F1I=&EO;G, 97AP<F5S<V5S+ T*:6UP;&EC:71E<R!O M=2!E;B!V97)T=2!D92!L82!L;VDL(&YO=&%M;65N=" H;&4 8V%S(.EC:.EA M;&EC:71E<R!D92!Q=6%L:73I(&UA<F-H86YD92P 9))A9&%P=&%T:6]N(. M=6X =7-A9V4-"G!A<G1I8W5L:65R+"!DDF5X86-T:71U9&4 ;W4 9))E>&AA M=7-T:79I=.D 9&5S('+I<&]N<V5S+"!D97, <NES=6QT871S+"!D97,-"F5F M9F]R=', 9.EP;&]YZ7, <V5L;VX ;&5S('+H9VQE<R!D92!LDF%R="P 9))A M;)+I9V%R9"!D=2!,;V=I8VEE;"!E="!D92!L82!P<F5S=&%T:6]N(&1E<R!S M97)V:6-E<R!D90T*<V]U=&EE;B!T96-H;FEQ=64 ;W4 9&4 ;))O;6ES<VEO M;B!DDG5N92!T96QL92!P<F5S=&%T:6]N+B" 4$%2($%)3$Q%55)3+"!)3 T* M" D)"3QP(&-L87-S/2(R849R96YC:%-U8FAE860B/CQA(&YA;64](E]2968T M;B!L86YG/2)&4B( <W1Y;&4])V9O;G0M<VEZ93HQ,BXP<'0[9F]N="UF86UI M34U!1T53+B!$04Y3($Q!($U%4U5210T*34%824U!3$4 4$5234E312!005( M("A.3U1!34U%3E0L($Q%4R!$3TU-04=%4PT*P"!,DLE'05)$($15($U!3E%5 M14Y44PT*0T].1DE$14Y4245,4R!/52!!551215,L($1%($Q!(%!%4E1%($22 M02!624],051)3TX 1$4 3$$ 5DE%(%!225;)12P 1$4 3))/34E34TE/3B!$ M3TY.12!&3TD 3U4 1))%6$520T52(%5.(%-/24X 4D%)4T].3D%"3$4L($1% M24%)4D4 3U4 05544D4 4$525$4 1$4 455%3%%512!.05154D4 455%($-% M4D5,051)5D5-14Y4(, 54Y%(%1%3$Q%($1)4U!/4TE424].+"!-RDU%($5. M24],051)3TX 1$4 0T].5%)!5"!/52!$12!624],051)3TX 1$4 1T%204Y4 M4\D 1$4 3$$-"E!/4U-)0DE,253)($1%(%1%3%, 1$]-34%'15,N/"]S<&%N M/CPO8CX\+V$^/"]P/ T*"0D)/' 8VQA<W,](C)A1G)E;F-H4W5B:&5A9"(^ M/'-P86X ;&%N9STB1E(B('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M M9F%M:6QY. T*(D)O;VL 06YT:7%U82(G/DQ)34E4051)3TX 1$4 4D534$]. M92!V;W5S('!U:7-S:65Z('-U8FER('!O=7( <75E;'%U92!M;W1I9B!Q=64 M8V4 <V]I=" H;F]T86UM96YT+"!T;W5S(&QE<PT*9&]M;6%G97, <W5S;65N M=&EO;F[I<R!E="!T;W5S(&QE<R!D;VUM86=E<R!D:7)E8W1S(&]U(&?I;NER M(&1E(&R2=6X ;W4 ;))A=71R92!D92!S97, 9F]U<FYI<W-E=7)S(&%U>"!T M97)M97, 9&4-"G1O=71E(&1I<W!O<VET:6]N(&1U('!RZ7-E;G0 155,02!E M92!Q=6D <'+I8^AD92!S92!L:6UI=&4 874 <&QU<R#I;&5VZ2!E;G1R92!L M97, ;6]N=&%N=', <W5I=F%N=',F;F)S<#LZ M;W5S(&%V97H <NEE;&QE;65N="!P87GI('!O=7( ;&4 3&]G:6-I96P ;W4 M;FES('%U:2!P<NECZ&1E;G0 *'D 8V]M<')I<R!L97, 8VQA=7-E<R!C:2UD M97-S=7,I+ T*<Y)A<'!L:7%U96YT(&1A;G, ;&$ ;65S=7)E(&UA>&EM86QE M;W5T(')E8V]U<G, ;I)A='1E:6YT('!A<R!S;VX 8G5T(&5S<V5N=&EE;"X\ M+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](C)A1G)E;F-H4W5B:&5A9"(^/'-P M86X ;&%N9STB1E(B('-T>6QE/2=F;VYT+7-I>F4Z,3(N,'!T.V9O;G0M9F%M M:6QY. T*(D)O;VL 06YT:7%U82(G/DQA('!RZ7-E;G1E($-O;G9E;G1I;VX M97-T('+I9VEE('!A<B!L97, ;&]I<R!D92!L82!P<F]V:6YC90T*9))/;G1A M<R!T<FEB=6YA=7 9&4 ;&$ <')O=FEN8V4 9))/;G1A<FEO(&5T(&-O;G-E M;G0 X"!I;G-T:71U97(-"G1O=70 ;&ET:6=E('%U:2!P;W5R<F%I="!DZ6-O M=6QE<B!D92!L82!P<NES96YT92!A=7!RZ', 9&5S('1R:6)U;F%U>"!S:71U MZ7,-"F1A;G, ;&4 9&ES=')I8W0 :G5D:6-I86ER92!D92!9;W)K+"!P<F]V M:6YC92!DDD]N=&%R:6\N/"]S<&%N/CPO<#X-" D)"3QP(&-L87-S/2(R849R M96YC:%-U8FAE860B/CQS<&%N(&QA;F<](D92(B!S='EL93TG9F]N="US:7IE M.C$R+C!P=#MF;VYT+69A;6EL>3H-"B)";V]K($%N=&EQ=6$B)SY!=2!C87, M;_D =F]U<R!A=7)I97H 9&5S('%U97-T:6]N<R!C;VYC97)N86YT(&-E='1E M(&QI8V5N8V4 ;W4-"G%U92!V;W5S(&3I<VER:65Z('9O=7, ;65T=')E(&5N M(')A<'!O<G0 879E8R!-:6-R;W-O9G0 <&]U<B!Q=65L<75E(')A:7-O;B!Q M=64-"F-E('-O:70L('9E=6EL;&5Z(&-O;G1A8W1E<B!L82!S=6-C=7)S86QE M($UI8W)O<V]F="!D97-S97)V86YT('9O=')E('!A>7,L(&1O;G0-"FR2861R M97-S92!E<W0 9F]U<FYI92!D86YS(&-E('!R;V1U:70L(&]U(.EC<FEV97H M($]N92!-:6-R;W-O9G0 5V%Y+"!2961M;VYD+"!787-H:6YG=&]N)FYB<W [ M.3 P-3(M-C,Y.2X\+W-P86X^/"]P/ T*"0D)/' 8VQA<W,](DUS;TYO<FUA M;"(^/'-P86X ;&%N9STB1E(B('-T>6QE/2=F;VYT+69A;6EL>3HB0F]O:R!! M;G1I<75A(B<^)FYB<W [/"]S<&%N/CPO<#X- ,/ T*/"]H=&UL/ T* ` end
Aug 16 2003
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Perhaps what you want is akin to the ability to pick out one name from a =
module, like so:
=3D=3D=3D=3D=3D=3D=3D=3Dfile A.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module A;
class B {}
...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;
import A.B; // just bring in class B from module A
Except you want to be able to do away with module A entirely.
What if such a file were missing a module declaration, and the only name =
present in it matches the file name?
=3D=3D=3D=3D=3D=3D=3D=3Dfile B.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
class B {}
...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;
import B; // just bring in class B from B.d
Hmm. It seems viable but I'm sure there would be other issues to work =
out. What if class B needs some "global" support declarations?
A workaround for now might be public imports.
=20
=3D=3D=3D=3D=3D=3D=3D=3Dfile A.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module A;
class B {}
...
=3D=3D=3D=3D=3D=3D=3D=3Dfile Stuff.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
public import A.B;
...
=3D=3D=3D=3D=3D=3D=3D=3Dfile C.d:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module C;
import Stuff.B; // just bring in class B from A.d, via public import in =
Stuff.d
I seem to recall D used to have this behavior by default, and private =
imports were added to compensate. So this might still work, I haven't =
checked. You could pull in everything you need into one big library =
interface module, even though it actually lives in its own module in its =
own file. But it requires such a library interface module. That's not =
such a stiff requirement though, as this kind of thing would be mostly =
for library work anyway.
Sean
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message =
news:bhme5o$jlf$1 digitaldaemon.com...
like templates (which are almost modules within modules) I think there =
there
is too much depth in the D names,
I think D needs a way to create a file that only contains one item, be =
that
a template, class, struct or other. so import a.b.c; looks for a/b/c.d =
as
it does now; only the item imported may be a.b.c
rather than a.b.c.t.c or a.b.c.c etc;
Aug 17 2003
You may try this instead of CVS: http://subversion.tigris.org/ Not a final version yet, but usable. Highlights: it has renames and atomic commit compared to CVS. "Charles Sanders" <sanders-consulting comcast.net> wrote in message news:bhm2ns$3dd$1 digitaldaemon.com...Great I was wondering about this, I remember alot of activity but don't remember what became of it. I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this ? I'm not trying to elect myself as leader to this, I just want to see it get off the ground. Thanks, lets hear some ideas! Charles "Walter" <walter digitalmars.com> wrote in message news:bhkq1t$1urm$1 digitaldaemon.com...I want to encourage everyone to help out with the library. My primaryfocus,as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, willtakeon the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class,sothe smallest app pulled in the entire library. Library modules should beasdecoupled as practical. Calling a directory function shouldn't pull in100kof bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especiallytheunittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.
Aug 16 2003
Walter wrote:I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat.Well if you build a library based on objects you will have branches of tight coupled classes. e.g all the List classes single linked, double linked etc will have features implemented in some base class. But I assume you were not talking about that kind of cohesion.2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires.That is a very good suggestion IMHO. On the other hand many know that library regularly and know the Ins/Outs...3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere.Would you mind to explain what you understand under core libraries? Are you talking about well known datastructures? I can't see any problem with a library if it's fully implemented in D. A list implementation will work on "all the platforms"4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly.This is a good idea. I think have something layered will work as usual. A very thin layer for "base services" and a lot of convenience libraries.5) Performance matters.Definitly for a base library.6) Size matters.Agreed. Anyway I would sacrify it quite bunch of the latter points for stability and even more important (IMHO) maintainebility.7) Make use of the in, out, invariant and unittest features, especially the unittest.Very very important. Don't forget the contracts!8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratchThat is really a BIG problem.9) Put your name in the code you write! You'll be famous as one of the D pioneers!In my opinion D offers quite a lot for library development, but library development is time consuming and getting libaries consistent is really hard to get right. I suggest checking the naming conventions in Eiffel as a design starting point. I have spend quite some time on library development but are very short on time beeing able to spend on free work.... Regards Friedrich
Aug 18 2003
Walter wrote:I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especially the unittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.If I try to boil this down, I arrive at: A) The primary design goal is efficiency. Priorities: A.1 Unbloated Executables (thin wrappers to APIs, loose coupling) A.2 Performance is more important than size (help the compiler / in out invariant) A.3 Runtime Size is important, but less than performance B) Secondary design goals B.1 Keep Windows and Linux in mind and on par B.2 Care about safety (unittests!) B.3 Care about copyrights (in doubt? rewrite!) Please correct me, where I'm wrong. Where shall OO fit in? Sometimes objects and object hierarchies result in increased coupling and bloat. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Aug 26 2003