ition with anonymous, immutable last parameter?
Just a few thoughts...
BR
Marcin Kuszczak
(aarti_pl)
an current situation.
Additionally using such framework is pure pleasure and you want miss
string SQLs even in current, bad situation :-)
Best Regards
Marcin Kuszczak
(aarti_pl)
yigal chripun pisze:
aarti_pl Wrote:
Walter Bright pisze:
Don wrote:
There's not many sensible operators anyway. opPow is the only missing
one that's present in many other general-purpose languages. The only
other ones I think are remotely interesting are dot and cross pro
Lutger pisze:
yigal chripun wrote:
aarti_pl Wrote:
There's nothing more hideous than all those frameworks in Java/C++ that
try to re-enginer SQL into functions, templates, LINQ, whatever. SQL *is*
a perfectly designed language for its purpose and it doesn't need to be
redi
not necessary to change
current behavior that `` defines string.
I think we have good possibility to open this door now. It can be even
implemented later, but I would wish just not to close this door now :-)
BR
Marcin Kuszczak
(aarti_pl)
Walter Bright pisze:
aarti_pl wrote:
I know that quite a few people here doesn't like to allow users to
define their own operators, because it might obfuscate code. But it
doesn't have to be like this. Someone here already mentioned here that
it is not real problem for programs in
bearophile pisze:
aarti_pl:
I think that proposed names exactly reflect the meaning. So I would say
it is perfectly consistent with D convention.
Dollars are money, but opDollar is not a member function that returns the price
of a struct. So I don't agree with you, or I don't
bearophile pisze:
aarti_pl:
T opInfix(string op)(T rhs) { ... }
T opPrefix(string op)(T rhs) { ... }
T opPostfix(string op)(T rhs) { ... }
So you can use opInfix to define operators like a ~~ b :-)
Exactly. But the question is if you *REALLY* need it :-) But IMHO the
answer is up to
Andrei Alexandrescu pisze:
aarti_pl wrote:
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's propos
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's proposal:
http://prowiki.org/wiki4d/wiki.cgi?Lan
was already writing about it some time ago:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81026
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81352
BR
Marcin Kuszczak
(aarti_pl)
aarti_pl pisze:
Andrei Alexandrescu Wrote:
aarti_pl wrote:
I forgot to throw a link:
http://www.dsource.org/projects/doost/browser/trunk/examples/util/serializer/FunctionTest.d
Cool, do you also have documentation?
Andrei
Well, that's definitely weak point of this library. :-)
Yo
Jacob Carlborg pisze:
On 11/13/09 16:03, aarti_pl wrote:
Jacob Carlborg Wrote:
On 11/13/09 00:13, aarti_pl wrote:
Andrei Alexandrescu pisze:
> But that being said, I'd so much want to start thinking of an
actual
> text serialization infrastructure. Why develop one lat
Bill Baxter Wrote:
> On Fri, Nov 13, 2009 at 12:13 AM, aarti_pl wrote:
> > Andrei Alexandrescu Wrote:
> >
> > Additionally I would like to mention that there is also great BinaryArchive
> > from Bill Baxter, which I didn't mention in my first post.
>
> T
Jacob Carlborg Wrote:
> On 11/13/09 00:13, aarti_pl wrote:
> > Andrei Alexandrescu pisze:
> > > But that being said, I'd so much want to start thinking of an actual
> > > text serialization infrastructure. Why develop one later with the
> > > mentio
Andrei Alexandrescu Wrote:
> aarti_pl wrote:
> > I forgot to throw a link:
> >
> > http://www.dsource.org/projects/doost/browser/trunk/examples/util/serializer/FunctionTest.d
> >
>
> Cool, do you also have documentation?
>
> Andrei
Well, that&
I forgot to throw a link:
http://www.dsource.org/projects/doost/browser/trunk/examples/util/serializer/FunctionTest.d
BR
Marcin Kuszczak
(aarti_pl)
aarti_pl pisze:
Andrei Alexandrescu pisze:
> But that being said, I'd so much want to start thinking of an actual
> text se
think it's worthy
and eventually might be included in Phobos, I would be interested to
work on it further. But I would definitely need some code/concepts review.
Unfortunately there is rather poor documentation. But you can find a lot
of unit tests in examples directory.
It's Boost licensed so no worries :-)
BR
Marcin Kuszczak
(aarti_pl)
Jeremie Pelletier pisze:
aarti_pl Wrote:
Hello!
This is just another reminder about ongoing voting about properties:
http://www.igsoft.net/dpolls/index.php
Current results:
* about 68% of responders want to have special syntax for properties
* from people wanting new syntax most people
n other modern languages. But then why in D we have so many of
them although no one really likes it (__traits, foreach_reverse,
_argptr, _arguments)?
And finally: why polls are not integral part of digitalmars web page? It
took me only one hour to set up this poll...
BR
Marcin Kuszczak
(aarti_pl)
bearophile pisze:
aarti_pl:
What you mean saying "attributes"?<
See for example:
http://en.wikipedia.org/wiki/Java_annotation
It's not an esoteric thing, It's a way to add some extra semantics to a program.
In a low-level language like D there are other possible pu
Ary Borenszweig pisze:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Nice! This proposal seems to be really better (more general and
extensible) than any property proposal before.
BR
Marcin Kuszczak
(aarti_pl)
Chad J pisze:
aarti_pl wrote:
I don't think that 23 voters can be representative for D community. If
you have clear opinion about how properties should work in D, then you
can express your opinion. Don't loose your chance :-)
The poll has been up for a bit more than 5 hours n
bearophile pisze:
> I agree, attributes (or something like that) are a better solution
to this (and other) problem.
What you mean saying "attributes"? Probably I missed some posts...
BR
Marcin Kuszczak
(aarti_pl)
Ary Borenszweig pisze:
Andrei Alexandrescu escribió:
Leandro Lucarella wrote:
aarti_pl, el 1 de agosto a las 16:44 me escribiste:
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added
additional pool about omissible parenthesis feature.
Here is the
ex.php
BR
Marcin Kuszczak
(aarti_pl)
Ok. Let's do some voting.
I extended pool with latest syntax suggestion. I also added additional
pool about omissible parenthesis feature.
Here is the link:
http://www.igsoft.net/dpolls/index.php
Let's vote and please do not kill my server ;-)
BR
Marcin Kuszczak
(aarti_pl)
elow:
* Introduce syntax 1 (also remove ommitable parenthesis feature)
* Introduce syntax 2 (also remove ommitable parenthesis feature)
* Introduce syntax 3 (also remove ommitable parenthesis feature)
* Remove ommitable parenthesis feature, not introducing new syntax
* Keep things as they are, resolving existing problems (+=) not
introducing new syntax
* Keep things as they are now
Thanks for suggestions!
BR
Marcin Kuszczak
(aarti_pl)
Robert Fraser pisze:
aarti_pl wrote:
Please add another syntax proposals (max. 2 best proposals - with
example code) and correct mistakes in questions (if any):
I like the C# style:
int size
{
get { return _size; }
set { _size = value; }
}
get, set and value are only "key
Jesse Phillips pisze:
aarti_pl Wrote:
Please notice that only one option should be chosen.
But the multiple options allow for better proportional representation in the
poll.
My point of view was that it will be easier to interpret results. And
also the result will be only one (one final
TS! I WANT
TO POST LINK TO POLL TOMORROW AFTER GETTING SOME FEEDBACK.
BR
Marcin Kuszczak
(aarti_pl)
---
Poll - Properties for D
int _size;
Syntax 1
property {
int size() {return _size;}
void size(int s) {_siz
Andrei Alexandrescu pisze:
Steven Schveighoffer wrote:
On Tue, 28 Jul 2009 16:08:58 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
However, when I see:
x.empty;
I can't tell what is implied here.
You can. In either C# or D language it could execute arbitrary code
that yo
plain design pattern it will be probably
removed later.
To succeed with this you will need to put into Wikipedia something
really special :-)
BR
Marcin Kuszczak
(aarti_pl)
ther. IMHO standard library should have API allowing one or other
approach depending on what user wants... So this difference is purely
rhetorical...
BR
Marcin Kuszczak
(aarti_pl)
www.zapytajmnie.com - my christian site
ects/doost/browser/trunk/doost/util/serializer
Best Regards
Marcin Kuszczak
(aarti_pl)
www.zapytajmnie.com - my christian site
g convention is another's worst.
Happy hunting :o).
Andrei
first - last
advance - retreat
Above seems to me much more streamlined, than current choice.
BR
Marcin Kuszczak
(aarti_pl)
nd not part of the
compiler.
Yah, that makes sense. I vote for foreach_reverse to go away, too.
Andrei
vote++
BR
Marcin Kuszczak
(aarti_pl)
e other project I'm
> involved with, I provide a link. If you actually want people to look
> at something that's what you gotta do. Just common sense, really.
> Especially when the name for the thing is something generic that
> Google probably won't work on.
>
> --bb
I agree, I also usually provide link every time I mention my libs.
Try this link - it works:
http://www.fantascienza.net/leonardo/so
BR
Marcin Kuszczak
(aarti_pl)
Andrei Alexandrescu pisze:
aarti_pl wrote:
Andrei Alexandrescu pisze:
downs wrote:
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I thi
Andrei Alexandrescu pisze:
aarti_pl wrote:
Andrei Alexandrescu pisze:
downs wrote:
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I thi
Andrei Alexandrescu pisze:
downs wrote:
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we need
to ground it in reality. What are th
Don pisze:
aarti_pl wrote:
DSL support in mother language. As an example I can give SQL in D or
mockup tests description language (usually also in D - not as a
separate script language).
Could you be more specific about this? For SQL, arithmetic and
logical operators don't seem
Don pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we need
to ground it in reality. What are the use cases?
I think that D's existing opCmp() takes care of the p
downs pisze:
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we need
to ground it in reality. What are the use cases?
I think tha
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we need
to ground it in reality. What are the use cases?
I think that D's existing opCmp() takes c
uch more handy to use "DSL in mother language" approach rather than
string mixins with DSL language itself.
BR
Marcin Kuszczak
(aarti_pl)
Kuszczak
(aarti_pl)
here, there are still arguments against mixins.
Please see my answer to Don's post.
BR
Marcin
(aarti_pl)
ith SQL queries.
I agree. In D raw operator overloading should be probably as
discouraging as cast operator :-)
e.g.
opRawEqual()
opRawNotEquals()
etc.
BR
Marcin Kuszczak
(aarti_pl)
.Where(id.EqualsTo(5));
downs way:
auto query1 = select(a) /where/ "id" /eq/ 5;
auto query2 = select(a) /where/ "name" /like/ "%bob%";
Nice, but I am not so sure that as much intuitive? :-)
BR
Marcin Kuszczak
(aarti_pl)
Don pisze:
aarti_pl wrote:
Andrei Alexandrescu pisze:
> We're trying to make that work. D is due for an operator overhaul.
>
> Andrei
Is there any chance that we get possibility to overload "raw
operators", like in C++? I think that they may coexist with cur
dennis luehring pisze:
aarti_pl schrieb:
Ary Borenszweig pisze:
dennis luehring escribió:
...
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
what speaks against an sql parsing mixin?
would be more expressive
e identifiers you can also get values from resulting table.
When I implement parts of expression in Column classes I will loose this
decoupling: someone who just wants my resulting table object + column
identifiers will have to see api for sql expressions, which he/she will
not use at all.
Best Regards
(aarti_pl)
system it won't be possible to automatically create
database, typesafely get results from resulting table and few other nice
features...
BR
Marcin Kuszczak
(aarti_pl)
can do with operator overloading
Please see additional points, which I put into answer for Ary.
BR
Marcin Kuszczak
(aarti_pl)
t environment, to define DSL-s
*in* D and *not* using unsafe strings.
BR
Marcin Kuszczak
(aarti_pl)
k this solution is much better than nothing. I assume it would
at least
work ok on standalone-type projects.
Aarti_pl:
Yeah... Also my thoughts...
Additionally maybe there are 3rd party object files converters, and
"Windows people" work could be done using them as workaround?
Aarti_pl pisze:
dsimcha pisze:
== Quote from Christian Kamm (kamm-incasoftw...@removethis.de)'s article
Speaking of LDC, any chance that the exception handling on Win32 gets
fixed in the near future?
No, unfortunately.
It's a problem with LLVM only supporting Dwarf2 exception han
maybe there are 3rd party object files converters, and
"Windows people" work could be done using them as workaround?
BR
Marcin Kuszczak
(aarti_pl)
started/not evaluated"
(see point 15 in status table).
BR
Marcin Kuszczak
(aarti_pl)
tic if(is(traits(isAssociativeArray, T))) {
traits(associativeArrayKeyType, K);
traits(associativeArrayValueType, V);
}
Compared to my proposal:
static if (T V K : V[K]) {
//V and K is already defined here
}
Anyway merging these two proposals will improve situation significantly.
BTW. I also hate underscores in keywords. :-P
Regards
Marcin Kuszczak
(aarti_pl)
Christopher Wright pisze:
Marcin Kuszczak wrote:
...
My db access layer solves above problems.
You have me drooling in anticipation.
Well, this solution works and really solves above mentioned problems for
me. I use it with real application and it works great.
But indeed it really might b
-> object -> relation.
I am working on db access framework which makes use of relations rather
than creating objects. And it makes it in typesafe way...
BR
Marcin Kuszczak
(aarti_pl)
63 matches
Mail list logo
