It's a Java way:

SimpleDateFormat formatter
= new SimpleDateFormat ("yyyy.MM.dd G 'at' hh:mm:ss a zzz");
Date currentTime_1 = new Date();
String dateString = formatter.format(currentTime_1);

Huh? =) OOP & here is no one "printf..."

// Dizel

and how much code do you need to write to perform a simple
prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and a
float %g, i,i,str1,str2,str1,f );

I would like to see an extended object array type that allows runtime type
checking or both objects and primitives
which could be used for a D varargs
without the Java problem of having to create a Integer, Long Object to wrap
the primatives passed in the array.

a good D svprintf would be a bonus too (that understood the buffer was a D char/wchar[] and could grow it for you).

Mike.

<dr_dizel@hotbox.ru> wrote in message news:an4qf6$2bio$1@digitaldaemon.com...
> It's a Java way:
>
> SimpleDateFormat formatter
> = new SimpleDateFormat ("yyyy.MM.dd G 'at' hh:mm:ss a zzz");
> Date currentTime_1 = new Date();
> String dateString = formatter.format(currentTime_1);
>
> Huh? =) OOP & here is no one "printf..."
>
> // Dizel
>
>

Mike Wynn wrote:
> and how much code do you need to write to perform a simple
> prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and a
> float %g, i,i,str1,str2,str1,f );
> 
> I would like to see an extended object array type that allows runtime type
> checking or both objects and primitives
> which could be used for a D varargs
> without the Java problem of having to create a Integer, Long Object to wrap
> the primatives passed in the array.

My port has safe varargs using a generic list:

   void print (char [] format, generic [] args...);

The generic struct holds a pointer and a TypeInfo.  I use it for printing, as with the above.  Go bug Walter about it, as he seems to think formatted printing isn't the most important library task in a wide range of applications and worth the fifty lines of code this took.  :-)

This also gets rid of the va_list issue with two functions for every varargs function as you can expand generic lists into another.  Example:

    void foobar (generic [] args...)
    {
        print ("%s:%d\n", args [1 .. ]...);
    }

And, of course, it fixes the issue of having to have at least one real argument.

> a good D svprintf would be a bonus too (that understood the buffer was a D
> char/wchar[] and could grow it for you).

It's just fmt in my port:

   char [] fmt (char [] format, generic [] args...);

   char [] str = fmt ("%s", 45);

So it's similar to Python in that you can pass anything through %s.

> My port has safe varargs using a generic list:
>
>     void print (char [] format, generic [] args...);
>
> It's just fmt in my port:
>
by 'Port' have you modified the D front end ? is so is this public and usable on Win32 systems ?

It seems that you've made some changes from the D standard in your port. Does Walter plan on supporting these things in the future?  Are these things temporal (likely to change)? What will happen if Walter takes a different approach and some of these things become obsolete?

Not saying what you have done is good or bad, I'm just asking some critical questions about your port.

PS -
Keep up the excellent work on the port.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:an52bu$2jb3$1@digitaldaemon.com...
> Mike Wynn wrote:
> > and how much code do you need to write to perform a simple
> > prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and
a
> > float %g, i,i,str1,str2,str1,f );
> >
> > I would like to see an extended object array type that allows runtime
type
> > checking or both objects and primitives
> > which could be used for a D varargs
> > without the Java problem of having to create a Integer, Long Object to
wrap
> > the primatives passed in the array.
>
> My port has safe varargs using a generic list:
>
>     void print (char [] format, generic [] args...);
>
> The generic struct holds a pointer and a TypeInfo.  I use it for printing, as with the above.  Go bug Walter about it, as he seems to think formatted printing isn't the most important library task in a wide range of applications and worth the fifty lines of code this took.  :-)
>
> This also gets rid of the va_list issue with two functions for every varargs function as you can expand generic lists into another.  Example:
>
>      void foobar (generic [] args...)
>      {
>          print ("%s:%d\n", args [1 .. ]...);
>      }
>
> And, of course, it fixes the issue of having to have at least one real argument.
>
> > a good D svprintf would be a bonus too (that understood the buffer was a
D
> > char/wchar[] and could grow it for you).
>
> It's just fmt in my port:
>
>     char [] fmt (char [] format, generic [] args...);
>
>     char [] str = fmt ("%s", 45);
>
> So it's similar to Python in that you can pass anything through %s.
>

anderson wrote:
> It seems that you've made some changes from the D standard in your port.
> Does Walter plan on supporting these things in the future?  Are these things
> temporal (likely to change)? What will happen if Walter takes a different
> approach and some of these things become obsolete?

Default arguments for array slicing will get in DMD; if they're not on Walter's TODO, they must be put there.

Safe varargs, as I say, require some convincing.  The alternatives are compile-time argument expansion and iostream.  He's publicly opposed iostream (to the point of wanting to restrict the operator overloading to disallow it, if you remember) - although it flat out will get into D if the only alternative is C's broken method - and I doubt he's much for compile-time argument expansion (Either the Russ method or the overloaded recursive method), as it's not a simple thing to do in the compiler, even with inlining there.

I'm convinced my solution is the absolute ideal for the generic list method - it does everything using the minimum of fuss and fits like the language had been built for it.  Choosing an inferior, and incompatible, method instead would be very strange seeing as it's so easy to implement; fifty lines isn't really any more complex than twenty or ten.  The only variation could be in the keyword and the supported methods.

There's no chance of obsoletion, as the generic list method does everything.

>  Go bug Walter about it, as he seems to
>think formatted printing isn't the most important library task

Walter consider yourself bugged, Mark

I'm not ignoring this issue, you're right, it does need addressing. It's just that I've got a pile of things to do to D. You're right about my dislike of C++ iostreams. The nail in its coffin is the poor performance on benchmarks. Iostreams has bloat, inefficiency, complexity, and is aesthetically unappealing. The only thing it does right is flexibility, but at too high a cost.

Java is worse, its I/O speed is a serious problem.

Paying a lot of attention to I/O routines is a crucial component of the speed of the Digital Mars compilers/linkers.