On Tuesday, 8 September 2015 at 17:22:44 UTC, NX wrote:
I have figure out
typo:
...I had to figure out...
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation.
Do you have any idea how much I struggled when I try to use enums
in OpenTK library because they were "encapsulated" ?
Whenever I read OpenGL tutorials I have figure out which
enum-name they used as
On that note, is there also any generic translation software for
code that you can program a set of simple "rules"(matching and
arranging) to translate source code?
e.g., match("const WM_", ";")->WM.add(%1 + ",")).
The above should be obvious but essentially it matches the first
string until
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:
const WM_* -> add to enum WM;
else WM_* -> WM.*
I'm against that. The documentation all says WM_* and we
shouldn't muck with it.
const -> enum is a good idea though. These headers were all
written way back when when const and
On Monday, 7 September 2015 at 20:55:25 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation. It prevents namespace pollution and
identifier collision.
This is already provided by the D module system. Even if you
were to define a
On Monday, 7 September 2015 at 22:21:28 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Oh, and who says you couldn't keep both systems?
Nobody. There's absolutely nothing stopping you from defining
your one constants and bindings. I think you should
On Monday, 7 September 2015 at 23:11:36 UTC, Prudence wrote:
I asked is there is an easy way to do it, and you replied that
essentially that it shouldn't be changed because it would
change things.
I also said:
I guessing one would need a D or C parser to deal with all
this?
hackerpilot's
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Again, it's called progress. Why keep using the same defunct
system for endless years simply because that's the way it was
done?
Any C library binding should maintain the same interface as the C
library as much as possible. That
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Oh, and who says you couldn't keep both systems?
Nobody. There's absolutely nothing stopping you from defining
your one constants and bindings. I think you should actually do
it and see for yourself the pros and cons in practice.
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation. It prevents namespace pollution and
identifier collision.
This is already provided by the D module system. Even if you were
to define a WM_CREATE in your code, it would not cause a major
problem with the
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:
because it is confusing and hard for you to understand over
Nope, I'm saying it is a pointless change. If you do that, EVERY
time you want to look something up, you need to rewrite WM.* into
WM_* since that's what the docs say. And
On Monday 07 September 2015 21:06, Prudence wrote:
> If you think mentally changing a . to a _ is a hassle then your
> in trouble! An apple a day simply won't help!
[...]
> Oh well, some people
> just don't like progress! Do you want to go back to using wooden
> wheels too?
[...]
> Get out of
On Monday, 7 September 2015 at 17:59:43 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:
const WM_* -> add to enum WM;
else WM_* -> WM.*
I'm against that. The documentation all says WM_* and we
shouldn't muck with it.
huh?
Are you saying you don't
On Monday, 7 September 2015 at 18:58:08 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:
because it is confusing and hard for you to understand over
Nope, I'm saying it is a pointless change. If you do that,
EVERY time you want to look something up, you
14 matches
Mail list logo
