On second thought, I came to an idea that it'd be nice
if all function pointers would be "universal" - that is,
able to point to global function as well to method.
Internally, it would be represented by a simple struct:

    struct
    {
        Object object;
        void* function;
    }

If pointer is to global function, the .object field
is null, otherwise, its value is used as "this" pointer
when calling method.

This requires twice as large memory for function pointers... But memory isn't an issue nowadays, especially considering that there aren't many function pointers in programs, and it is very unlikely to have arrays of them. On other hand, methods could be used in any situation where callback is required, which can be damn useful.

As an example, consider WindowProc callback. In MDI application,
there are several (child) windows which are represented by
instances of a single class. It would be great if I could use
a method as a WindowProc, but no, I have to define a single
static method, make a linked-list of all windows and scan
through it each time I get a message to determine which window
should handle it... of course, nothing can be done here, but
at least similar situations in libraries written in D could be
prevented.

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sjljv$v8m$1@digitaldaemon.com...
> If module B imports module C, and module A
> imports B, does A import C?

Scoping issues aside, yes.

Walter wrote:
> 
> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message
> > "Walter" <walter@digitalmars.com> wrote in message
> > > > Suppose I have the following declaration:
> > > >     int* x, y;
> > > > Is y an int or a pointer to int?
> > > An int. I didn't break away from C on that one. I can be persuaded otherwise.
> > Yes, yes!
> > Should we start collecting votes for a petition? =)
> 
> I'm more interested in compelling arguments  (!)

	How about I call my family in New Jersey?  :-)  Seriously though, in
the above example you would think

	<type> <var1>, <var2>;

where var1 and var2 are both of type.  Anyone who is not "used" to C's interesting interpretation of this sort of declaration (and may who are used to it) will get burned.  The syntax definite isn't too clean nor too popular to be tampered with.  I'd try harder to argue, but it looks like others are doing a good job of convincing you.

Dan

"Walter" <walter@digitalmars.com> wrote in message news:9skeha$1dh9$2@digitaldaemon.com...

> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sjljv$v8m$1@digitaldaemon.com...
> > If module B imports module C, and module A
> > imports B, does A import C?
>
> Scoping issues aside, yes.

So there's no way to import a module for my own,
"private" use?

Something like that:

    import vector;        // this is visible to everybody
    private import math;  // this is used internally and thus is visible
only to myself

And then, forbid any constants and types from private- imported modules to be used in public declarations?

"Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...

> I'm more interested in compelling arguments  (!)

Suppose we have the following code:

    int*[]* x, y;

"Old" way: x is pointer to array of pointers, y is an array of
    pointers. The first asterisk applies to both, the second
    is applied only to x. Not only it's weird, but just try to
    define a _clear_ rule (say, for the specification) that
    strictly defines meaning of asterisk.

New way: both are pointers to array of pointers. Anything
    that's on the left is part of the type and is applied to
    all variables on the line, no special cases and
    exceptions.

I vote for the new one...

Walter wrote:

> 
> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdigb$2715$1@digitaldaemon.com...
>> What is the default attribute for class members
>> (private/protected/public)?
> 
> Public. I always thought that C++'s way just made for annoying extra typing when banging out quick code. A production quality class should always say it explicitly.

I say private would be better for quality code.

Argueing for this is quite simple, if there is nothing standing there you can suppose that programmer simply forgot about the access attribute.

If he actually ment private, but public is default, he gets no compiler
errors/warnings.
If he actually ment public, but private is default, the compiler will point
him on the failure.

- Axel
-- 
|D) http://www.dtone.org

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in news:9slgrh$241h$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...
>
> > I'm more interested in compelling arguments  (!)
>
> Suppose we have the following code:
>
>     int*[]* x, y;
>
> "Old" way: x is pointer to array of pointers, y is an array of
>     pointers. The first asterisk applies to both, the second
>     is applied only to x. Not only it's weird, but just try to
>     define a _clear_ rule (say, for the specification) that
>     strictly defines meaning of asterisk.
>
> New way: both are pointers to array of pointers. Anything
>     that's on the left is part of the type and is applied to
>     all variables on the line, no special cases and
>     exceptions.
>
> I vote for the new one...

PLEASE don't do that!
Don't change the meaning while keeping the sintax!

I think the ',' in declarations is useless, and error prone, so it's best to remove it.

Write:

int*[]* x;
int*[]* y;

And it works in C, C++, and D.

Ciao

"Axel Kittenberger" <axel@dtone.org> wrote in news:9so2i6$nhi$1@digitaldaemon.com...
> Walter wrote:
>
> >
> > "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdigb$2715$1@digitaldaemon.com...
> >> What is the default attribute for class members
> >> (private/protected/public)?
> >
> > Public. I always thought that C++'s way just made for annoying extra typing when banging out quick code. A production quality class should always say it explicitly.
>
> I say private would be better for quality code.
>
> Argueing for this is quite simple, if there is nothing standing there you can suppose that programmer simply forgot about the access attribute. [snip]

I think the compiler shouldn't compile a class with no 'public', 'private'
or 'protected'
at all. The user clearly forgotten to specify.

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:9so8hl$rln$1@digitaldaemon.com...

> I think the ',' in declarations is useless, and error prone, so it's best
to
> remove it.

Never ever!

> Write:
>
> int*[]* x;
> int*[]* y;
>
> And it works in C, C++, and D.

First, it won't work in C/C++ since they don't
support dynamic arrays.

And if you are concerned about compatibility, you
can write this way of course, but why forbid
the other ways?

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9so2i6$nhi$1@digitaldaemon.com...
> Walter wrote:

> I say private would be better for quality code.
>
> Argueing for this is quite simple, if there is nothing standing there you can suppose that programmer simply forgot about the access attribute.
>
> If he actually ment private, but public is default, he gets no compiler
> errors/warnings.
> If he actually ment public, but private is default, the compiler will
point
> him on the failure.

The thing is, when you omit the attribute at all, you get all members private, and the result is that class is completely useless.

As for "actually ment private" - I believe that when declaring classes, it's better to define public members first, since there are more people who want to know the interface of the cass than those that are interested in implementation.