While I hear a lot of experienced programmers take this point of
view, I still don't really understand or agree with it. I believe
a good language should facilitate good design, but I don't think
it should force it. I imagine this type of principal may simplify
code review for large projects, b
On Mon, 08 Dec 2014 02:58:45 +
bitwise via Digitalmars-d wrote:
> > if you want to allow external pragmas that allows poking
> > private module
> > data... well, just make everything in that module public, you
> > just
> > killed the whole protection thing. ;-)
>
> This is what I mean, but
if you want to allow external pragmas that allows poking
private module
data... well, just make everything in that module public, you
just
killed the whole protection thing. ;-)
This is what I mean, but I don't think it would 'kill' anything.
It's not like I'm suggesting that cast(public) be
On Sun, 07 Dec 2014 21:44:51 +
bitwise via Digitalmars-d wrote:
> I would like to be able to reflect private members though... Is
> there any way to give a module private access to an unrelated
> module?
nope. and i hope there will be no such thing. ;-)
> I understand that packages are meant
On Sunday, 7 December 2014 at 06:25:48 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 07 Dec 2014 05:42:31 +
bitwise via Digitalmars-d wrote:
what you actually want is some cross-module compile-time data
storage.
this is impossible to implement. at least to make it reliable.
with separate
On Sun, 07 Dec 2014 05:42:31 +
bitwise via Digitalmars-d wrote:
what you actually want is some cross-module compile-time data storage.
this is impossible to implement. at least to make it reliable.
with separate compilation, for example, you can't get list of "all
modules", 'cause we can lin
why don't create a dummy module which only keeps list of all
known
objects, and create `shared static this ()` constructors which
will
just register everything in that module?
I am actually doing this already, but this only solves for
finding information at runtime.
One or more of these are
On Sun, 07 Dec 2014 01:12:52 +
bitwise via Digitalmars-d wrote:
> If the reflection mixin is in the same module that it's
> reflecting, it can be easily found, but in the case of a static
> library where reflection information has to be created in a
> separate module, other modules won't b
why do you need that?
I've made a reflection library which creates metadata on a
per-module basis.
usage would be like this:
[code]
module test;
// classes, methods, etc..
mixin(reflect!test); // generates reflection here so private
members are accessible
[/code]
-or-
[code]
module ma
On Sat, 06 Dec 2014 20:22:12 +
bitwise via Digitalmars-d wrote:
> Hi,
>I have a mixin, which can mix a class into any module. At
> compile time, I will know the name of the class, it's base class,
> and that it is at global scope in some module.
>
> Is there any way to find this class
On Saturday, 6 December 2014 at 20:22:13 UTC, bitwise wrote:
Hi,
I have a mixin, which can mix a class into any module. At
compile time, I will know the name of the class, it's base
class, and that it is at global scope in some module.
Is there any way to find this class from a different mo
Hi,
I have a mixin, which can mix a class into any module. At
compile time, I will know the name of the class, it's base class,
and that it is at global scope in some module.
Is there any way to find this class from a different module at
compile time?
Thanks
12 matches
Mail list logo
