View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2012
Re: Do we need Win95/98/Me support?
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
news:ikyrsnddezjxlhukvnzl@dfeed.kimsufi.thecybershadow.net...
> On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
>> 1. *Allow* people to use the XP UI (and no, I don't mean Luna).
>
> You can...
>

No you can't. Note I said "UI", not "window theme". Even the third-party 
"Classic Shell" only takes things part-way (apperently, that's as far as 
it's even *able* to take things).
January 23, 2012
Re: Do we need Win95/98/Me support?
On Monday, January 23, 2012 00:31:24 Nick Sabalausky wrote:
> But you know, the really bizarre thing is, *all* MS has to do to win over
> all the XP people (or at least the majority of them) is two simple things:
[snip]

That may help, but it wouldn't be enough. There are companies which refused to 
go to XP service pack 3 (and maybe service pack 2 - I don't remember) because 
it broke software that they had (particularly software that had to do with 
keeping track of what employees did on their computers IIRC). If a service 
pack broke that, there's no way that they'd upgrade to Vista or 7.

Also, there are tons of Windows users who see no reason to upgrade. Why 
bother? Especially when it costs money? If they get a new computer which has 
Windows 7 on it, fine, but they won't upgrade their existing systems. XP works 
fine.

And when you consider the IT guys, they frequently want everyone on exactly 
the same OS, and they don't want to bother upgrading anyone, so they avoid 
upgrading for as long as possible.

Heck, my Dad was ticked with XP for being more of a resource hog than Win2K 
and refused to upgrade to XP until he absolutely had to recently because of 
issues with Norton. He's certainly not going to mess with Vista or 7 with 
their fancy UIs until he absolutely has to. There's nothing that Vista or 7 
offers that he considers worth the upgrade.

There are plenty of reasons to not upgrade. I don't think that Microsoft _can_ 
really do anything to get everyone to upgrade short of refusing to support XP 
any longer, which would result in a ton of ticked off customers. Sure, they 
could do some stuff to make more people willing to upgrade, but in the long 
run, the only thing that's going to get people in general off of XP is the fact 
that they won't be able to get it for new computers, so when they get a new 
computer, they end up with whatever the newest version of Windows is.

- Jonathan M Davis
January 23, 2012
Re: Do we need Win95/98/Me support?
On 1/22/2012 9:06 PM, Jonathan M Davis wrote:
> On Sunday, January 22, 2012 20:58:33 Walter Bright wrote:
>> Why make std.file support wchar and dchar? You triple the number of
>> functions, all for rarely used cases, and one where the user can trivially
>> convert wstring to string at the call site.
>
> It doesn't triple the number of functions. You just templatize them. You only
> get triple the number of functions if you actually use them with all 3 string
> types. But we've had complaints in general about Phobos functions only
> supporting string rather than char[] or wstring or whatever. Templatizing
> std.file's functions on string types helps alleviate that. And on Windows, it
> would even allow you to pass a wstring without having to convert to a string
> first and then back to a wstring to pass to the Windows API functions, which
> could reduce that number of string operations required for file operations.
> Regardless, the idea is to make the functions more flexible. They don't _need_
> to be restricted to string specifically.

Templatizing is not the answer. The operating system file APIs take only wchar[] 
(Windows) and char[] (every one else). That means that two of the three will be 
nothing more than wrappers, anyway.

Doing it as templates that means that any user of std.file has to read in the 
entire implementation of it, and everything std.file imports, rather than simply:

   void[] read(string filename);

And yet nothing is accomplished, because two of the three will *necessarily* be 
wrappers.

It's not an efficiency consideration because the conversion cost is meaningless 
next to the cost of opening a file.

This triples the number of functions in practice, and becomes what I dread - a 
library that is miles wide and an inch deep. We need *depth*, not trivia. These 
one line wrappers are *trivia* because they take longer to look up the 
documentation for than simply converting the string yourself as necessary. 
Trivia does not belong in Phobos.

Another way of looking at it is Phobos should provide snap-together building 
blocks, not trivial combinations of them.
January 23, 2012
Re: Do we need Win95/98/Me support?
On Sunday, January 22, 2012 22:56:23 Walter Bright wrote:
> Templatizing is not the answer. The operating system file APIs take only
> wchar[] (Windows) and char[] (every one else). That means that two of the
> three will be nothing more than wrappers, anyway.
> 
> Doing it as templates that means that any user of std.file has to read in
> the entire implementation of it, and everything std.file imports, rather
> than simply:
> 
>     void[] read(string filename);

That happens anyway, because Phobos doesn't use .di files.
    
> And yet nothing is accomplished, because two of the three will *necessarily*
> be wrappers.
>
> It's not an efficiency consideration because the conversion cost is
> meaningless next to the cost of opening a file.
> 
> This triples the number of functions in practice, and becomes what I dread -
> a library that is miles wide and an inch deep. We need *depth*, not trivia.
> These one line wrappers are *trivia* because they take longer to look up
> the documentation for than simply converting the string yourself as
> necessary. Trivia does not belong in Phobos.
> 
> Another way of looking at it is Phobos should provide snap-together building
> blocks, not trivial combinations of them.

Aside from the toMBSz issue, templatizing them costs essentially nothing on 
the implementation side and yet enables the programmer to pass in whatever 
string type they want. The only issue is that if you were using a .di file 
(which we're not, and won't, because it kills inlining and CTFE - though 
neither affects std.file much), you'd then have to have the implementation in 
the .di file whereas currently you don't.

So, as far as I can see, templatizing them costs us nothing (aside from the 
toMBSz issue) and makes the functions more flexible.

Now, I don't think that it's all that big a deal that you have to convert 
whatever string type you're using to string to pass to functions in std.file, 
but I pretty always use string anyway. Other folks have complained in the 
newsgroup about the fact that Phobos functions generally force them to use 
string specifically. So, it seemed like a no-brainer to just templatize the 
std.file functions on string type. toUTFz makes it trivially possible everyone 
but on pre-Win2K systems which have to worry about their strings being ANSI 
instead of UTF-8.

- Jonathan M Davis
January 23, 2012
Re: Do we need Win95/98/Me support?
On 1/22/2012 11:08 PM, Jonathan M Davis wrote:
> That happens anyway, because Phobos doesn't use .di files.

Phobos should use much more .di files. This will become more and more of an 
issue over time, as Phobos grows in complexity. We shouldn't preclude .di files.


> Aside from the toMBSz issue, templatizing them costs essentially nothing on
> the implementation side and yet enables the programmer to pass in whatever
> string type they want.

Phobos1 had the secant and cosecant functions, which were dumped for Phobos2. 
You could make exactly the same argument for them. It is an insufficient rationale.

Phobos functions should do non-trivial things. It should not become an 
aggregation of trivia.


> The only issue is that if you were using a .di file
> (which we're not, and won't, because it kills inlining and CTFE - though
> neither affects std.file much), you'd then have to have the implementation in
> the .di file whereas currently you don't.

I agree that inlining and CTFE is a complete non-issue for std.file. It is not 
the reason that std.file is not a .di file - the reason is that nobody bothered 
to do the work to make it one. It should be one.


> Now, I don't think that it's all that big a deal that you have to convert
> whatever string type you're using to string to pass to functions in std.file,
> but I pretty always use string anyway. Other folks have complained in the
> newsgroup about the fact that Phobos functions generally force them to use
> string specifically.

Nobody is forced to use string. Just do a trivial conversion on calling the 
function. I emphasize trivial. A phobos function is even provided to do that - 
to!(string)(arg).

Note that std.regex is templatized on the string type. This is necessary because 
regex performance is critical. This rationale does not apply to std.file.
January 23, 2012
Re: Do we need Win95/98/Me support?
Well, regardless of whether we want to templatize anything in std.file or turn 
it into a .di file or anything else we might want to do to, I think that 
useWfuncs and the corresponding support for Win9x should be dropped.

- Jonathan M Davis
January 23, 2012
Re: Do we need Win95/98/Me support?
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jfj0ao$3q9$1@digitalmars.com...
>
> Another way of looking at it is Phobos should provide snap-together 
> building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the 
*user's* code instead?

"Phobos: Batteries not included"
January 23, 2012
Re: Do we need Win95/98/Me support?
On 1/23/2012 1:14 AM, Nick Sabalausky wrote:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:jfj0ao$3q9$1@digitalmars.com...
>>
>> Another way of looking at it is Phobos should provide snap-together
>> building blocks, not trivial combinations of them.
>
> So whenever there's trivia to be done, it should be cluttering up the
> *user's* code instead?

It's a very successful strategy used in Unix, which does not have a tool for 
everything, but one can easily construct a tool for everything by stringing 
together components with |
January 23, 2012
Re: Do we need Win95/98/Me support?
On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
> can they? Talk about digging one's own grave. Heck, I wouldn't 
> be surprised if Vista and Win7 (and Win8) have not only caused 
> people to stick with XP, but also caused a lot of Win->Lin 
> converts - I'm getting closer and closer to that myself.

Well, bought new notebook recently and decided there's no 
difference between migrating to win7 and linux, tried ubuntu 11 
and linux mint 12, got too bad user experience with them. Linux 
causes high CPU load in idle mode - critical for notebooks - and 
that's in comparison with win7 loaded with OEM crapware. If you 
want vdpau (dxva for linux), you'll need nvidia driver, but its 
installation is poorly automated and I had to install it from 
nvidia site without automatic dependency resolution. Also hit one 
bug with Empathy IM software. So linux still seems not an option 
to me.
January 23, 2012
Re: Do we need Win95/98/Me support?
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jfjclq$slu$1@digitalmars.com...
> On 1/23/2012 1:14 AM, Nick Sabalausky wrote:
>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>> news:jfj0ao$3q9$1@digitalmars.com...
>>>
>>> Another way of looking at it is Phobos should provide snap-together
>>> building blocks, not trivial combinations of them.
>>
>> So whenever there's trivia to be done, it should be cluttering up the
>> *user's* code instead?
>
> It's a very successful strategy used in Unix, which does not have a tool 
> for everything, but one can easily construct a tool for everything by 
> stringing together components with |

It works in Unix because the building blocks are (mostly) well-designed and 
cover all needed use-cases.

I think you'd have a hard time finding a Unix parallel to "Scatter 
to!blah(blah) all over your code in every single call to every fucking 
standard function that involves a string whenever you want your code to deal 
with wstring or dstring instead, or invent your own PhobosPlus on top of 
Phobos to paper up all the existing use-case holes." If you did, I'd 
probably consider it a blemish where a Unix component screwed up with 
modularity.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home