On Wed, 19 May 2004 19:08:30 +0800, J Anderson wrote:

> Derek wrote:
> 
>>Yes, its true that it is possible to do 'readonly' in D already, and yes I did know that. What I was trying to do was suggest an ALTERNATE method, one that didn't involve a function call overhead.
>>
> 
> What overhead?  The function can easily be inlined.  The only difference would be the syntax form.

When you say that 'The function can easily be inlined' do you mean that any function one nominates will definitely be inlined? How does one indicate that in the source code?

I was under the impression, after reading the D docs, that a function might not be inlined sometimes. The docs say ...

---------
There is no inline keyword. The compiler makes the decision whether to inline a function or not, analogously to the register keyword no longer being relevant to a compiler's decisions on enregistering variables. (There is no register keyword either.)
----------

So I naturally assumed that there is a possibliity that the compiler might generate a function call.

My suggestion was designed to tell the compiler that its okay to generate direct accessing code when any code is reading the data element's value.

Sorry for misunderstanding the docs.

-- 
Derek
Melbourne, Australia

Derek wrote:

>
>When you say that 'The function can easily be inlined' do you mean that any
>function one nominates will definitely be inlined? How does one indicate
>that in the source code? 
>
>I was under the impression, after reading the D docs, that a function might
>not be inlined sometimes. The docs say ...
>
>---------
>There is no inline keyword. The compiler makes the decision whether to
>inline a function or not, analogously to the register keyword no longer
>being relevant to a compiler's decisions on enregistering variables. (There
>is no register keyword either.) ----------
>  
>
One line functions are obvious candidates for the compiler to inline and most compilers can inline these. There are some cases where it can't inline, such as with some virtual functions.  However these are rare and the overhead is generally acceptable.  Trust your compiler to make the better choice.

>So I naturally assumed that there is a possibliity that the compiler might
>generate a function call. 
>
>My suggestion was designed to tell the compiler that its okay to generate
>direct accessing code when any code is reading the data element's value.
>
>Sorry for misunderstanding the docs.
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/

Problem solved, I think. I haven't actually tried this, but I don't see any reason why it shouldn't work. Here's how you do it.

Suppose you wish to have four separate source files, which we shall call call john.d, paul.d, george.d and ringo.d.

You also wish that each of these source files should be able to access private data in each of the other source files, so that the collection of source files forms a single module, which we shall call beatles.

Easy peasy.

The content of john.d becomes:

>       module john;
>
>       template TJohn
>       {
>           public
>           {
>               // public declarations
>           }
>
>           private
>           {
>               // package-level declarations
>           }
>       }

That is, you wrap the WHOLE FILE inside a parameterless template declaration, and remove any import statements. The content of paul.d, george.d and ringo.d are similarly wrapped in a template declaration.

Finally, you create one extra source file for the package as a whole - beatles.d - whose content is as follows:

>       module beatles;
>
>       // imports required by ANY of the other source files go here
>
>       import john;
>       import paul;
>       import george;
>       import ringo;
>
>       mixin TJohn;
>       mixin TPaul;
>       mixin TGeorge;
>       mixin TRingo;

I think that should do the trick.

Arcane Jill

"Derek Parnell" <derek@psych.ward> wrote in message news:c8e98t$2qph$1@digitaldaemon.com...
> On Tue, 18 May 2004 22:55:13 +0300, Achilleas Margaritis wrote:
>
> >> For example, it may very well be that you write a bunch of GUI classes which need to cooperate with some kind of window system. As said
before,
> >> maybe you don't want these cooperation mechanism to be accessible by anything but the window system and the GUI classes. So with the current situation you'd have to put a good sized chunk of the library into one single file. We're talking about tens of thousands, maybe even hundreds of thousands of lines of code here. It would be impossible to have multiple programmers work on the library without regular merging
> > nightmares.
> >
> > I totally agree, very good example. To put in real terms, in most GUI toolkits, the graphics/device context in a Graphics type object that provides the drawing algorithms to widgets. Most toolkits base Widget
class
> > has a 'paint' method which is passed a Graphics object which is used for drawing by the widget.
> >
> > For example, Swing has a Graphics object; Qt has a Painter object.
> >
> > With the D method, one needs to put the Graphics class and the Widget
class
> > in the same file...which probably means around 20,000 lines of code in
the
> > same module.
>
> Only if you wish to directly access each other's internal data elements rather than use public methods.
>
> > This big file will contain all the implementations of the
> > Graphics class (for MS Windows / X-Windows / MacOS), and it needs to be
in
> > the same file with Widget because it needs access to the window handle
of
> > the widget. And the Widget class itself would be thousands of lines of
code,
> > covering functionality between Win32/X/MacOS.
>
> What wrong with a getWindowHandle() method?

You don't want to do that. Somebody might mess with the window that way and make a mess of your code.

>
> > It's a pity that the D community does not understand this. Most guys
think
> > it is no big problem. Unless you work on a big project, you can't
understand
> > what a problem can it be.
>
> I dislike huge source files too. I see no necessary linkage between a source code file and a D module either, other than this is how Walter has chosen to implement it.
>
> > Despite all this, D has the concept of package, right ? what if two
classes
> > want to co-operate in package level, but they don't belong in the same module ? i.e. they are not closely related, but they have to access a
few of
> > each other's internals.
> >
> > I repeat, this is a serious issue.
>
> Why can't access be via public *methods*? Why is the use of *private* (but friendly shared) data elements required? I don't see the seriousness of your situation. Can you give me code examples where you _need_ (as opposed to _want_ ) this? Is it a performance issue?

The Graphics object needs to access the handle of the window, but the programmer must not have access to the handle of the window. Otherwise, it would be easy to make a mess of a program.

>
>
> As I said before, maybe a read-only attribute might be an acceptable solution. One could then create something like ...
>
> class Widget
> {
>    readonly hWnd myHandle;
>
>    setHandle( ... ) { ... }
> }
>
> which would make 'myHandle' publicly visible but only to read its
contents.
> No one can set it other than the Widget class.
>
> --
> Derek
> 19/May/04 10:11:14 AM

Achilleas Margaritis wrote:

>The Graphics object needs to access the handle of the window, but the
>programmer must not have access to the handle of the window. Otherwise, it
>would be easy to make a mess of a program.
>  
>

I don't know about that.  I've always been annoyed with API's that don't provide a window handle because it makes adding openGL harder.  However I think something like a windows handle could be kept in a platform-specific module.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Achilleas Margaritis wrote:
> 
>> The Graphics object needs to access the handle of the window, but the
>> programmer must not have access to the handle of the window. Otherwise, it
>> would be easy to make a mess of a program.
> 
> I don't know about that.  I've always been annoyed with API's that don't provide a window handle because it makes adding openGL harder.  However I think something like a windows handle could be kept in a platform-specific module.

I totally agree.  Sometimes the toolkit doesn't do something you want, or you want to extend it with some third party UI element (like Scintilla).  If you can't reach the metal, you can't do that at all.

The solution is to simply document very clearly that it is "dangerous" and that it should not be used frivolously.

 -- andy