On Sunday, 9 December 2012 at 16:50:55 UTC, Ali Çehreli wrote:
On 12/09/2012 01:42 AM, js.mdnq wrote:
> Actually, it doesn't seem to work ;/ Your code worked but
mine does
> unless I make it public. It is a public/private issue and I
get a ton of
> errors:
This is not adding to the discussion much but it is again
because the member is private. writeln() is in a separate
module, which cannot access a private member of another module.
(Actually it is std.traits.isImplicitlyConvertible that can't
access that member.):
class A
{
struct B(T)
{
private:
//public:
T Value;
public:
alias Value this;
T opAssign(F)(F v)
{
//writeln(Name ~ " ...");
Value = cast(T)v;
return Value;
}
}
B!int b;
}
// Copied from isImplicitlyConvertible
template isImplicitlyConvertible_LOCAL(From, To)
{
enum bool isImplicitlyConvertible_LOCAL = is(typeof({
void fun(ref From v)
{
void gun(To) {}
gun(v);
}
}));
}
import std.traits;
int main(string[] argv)
{
A c = new A();
c.b = 34;
static assert(isImplicitlyConvertible_LOCAL!(A.B!int,
int)); // PASSES
static assert(isImplicitlyConvertible !(A.B!int,
int)); // FAILS
return 0;
}
> So while it might "work" in the simple case it doesn't seem
to actually
> work...
I am not sure that it should work. If it is private, maybe it
should stay private.
What you seem to need is read-only access to a private member.
There are other ways of achieving that. The following program
uses both a read-only property function and an 'alias this':
module main;
import std.stdio;
class A
{
struct B(T)
{
private:
//public:
T Value_;
public:
// read-only accessor
T Value() const @property
{
return Value_;
}
// Automatic conversion to the read-only accessor
alias Value this;
T opAssign(F)(F v)
{
//writeln(Name ~ " ...");
Value_ = cast(T)v;
return Value_;
}
}
B!int b;
}
int main(string[] argv)
{
A c = new A();
c.b = 34;
writeln(c.b);
getchar();
return 0;
}
Ali
but b is not private, only the internal representation of it.
e.g., `alias Value_ this` is public. I do realize that it sort of
makes Value_ and b one and the same but they are not quite the
same.
To me, it breaks encapsulation. writeln(c.b) is accessing b, not
Value_. b is a "virtual type" in the sense that it wraps Value_.
While it seems to do something funky like change the protection
of Value_ from private to public it doesn't. There is no way to
access Value_ when it is private. i.e., we can't do c.b.Value_;
To drive the point home. We could/should be able to completely
encapsulate `Value_` by overriding opAssign and add getters and
setters so that `Value_` is actually never even used(although
pointless then).
Another way to see this:
struct sPassword
{
private:
string Password;
public:
alias this Password;
opAssign
opCast
opCmp
opGet { return "******"; }
Change(old pass, new pass) { if ... }
Validate(pass) { pass == Password; ... }
}
sPassword myPass;
writeln(myPass) same as writeln(myPass.Get()) which prints ******
Such a type would be very secure. There is no way to get at
Password(except through looking directly at memory, but we could
encrypt it to make it difficult). But for all practical purposes
myPass acts like a password.
We can't accidently display the password to the user(in fact,
there is no way unless a method is added to return the password,
in which case there is no reason to make Password private.
In any case, it just seems to me that we should be able to use
private this way. If we want the additional functionality we just
make it public.
(it does sort of seem sPassword is like a readonly type but it's
more than that as it encapsulates completely)
Now, if Password was public instead of private, anyone could do
myPass.Password to get the password.
(the code isn't meant to be working D code but just a mix of
pseudo and hypothetical D code)
