January 23, 2012
"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
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
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
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
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
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
"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
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
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
"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.