Redis client

Pedro Lacerda pslacerda at gmail.com
Mon Mar 5 07:45:11 PST 2012


Dmitry, very thanks for the reply!

I'm going to make a nice API and acceptance testing using some Redis
tutorial. With it working well do you think that worth make project
marketing considering the overall code quality?

Looking the sources pedantically what's wrong?

Pedro Lacerda



2012/3/5 Dmitry Olshansky <dmitry.olsh at gmail.com>

> On 05.03.2012 7:24, Pedro Lacerda wrote:
>
>> In an attempt to learn D and git I'm building a Redis client. Assertedly
>> there are many problems in the implementation, I'd like to hear opinions
>> pointing them or suggestions. If here isn't the place to ask these type
>> of review, where is?
>> github.com/pslacerda/dredis <http://github.com/pslacerda/**dredis<http://github.com/pslacerda/dredis>
>> >
>>
>
> You may go for D group, though for newbie kind of thing D.learn is perfect
> place.
>
>
>
>> Some friend asked why I choose not to go asynchronous. It's because
>> usually clients and servers are at a very fast connection and Redis
>> responses are pretty fast too.
>>
>
> Right, and you always can go fancy later on :)
>
>
>
>> Correct me if wrong, but I need to do nothing special at
>> client.RedisClient to make it thread safe, right?
>>
>>  In a sense. I mean everything is thread-local by default so unless you
> plan to go _shared_ it's OK.
>
>
>  token.__Bulk has an nullable array because I made distinction between an
>> empty and a null arrays as the protocol did. The type looks fully bad.
>> Some idea?
>>
>
> Just use plain Nullable!(T[]) as is? I mean there is no need to wrap
> wrapper type ;)
>
>
>
>> I guess that make token.Token an struct and pass it through ref
>> functions will make the code somewhat better, but I have no clues. Token
>> will never be seen by the user. When should I do it?
>>
>
> Make it a struct, from the looks of it it's a tagged union anyway. More
> importantly passing it _by value_ and copying is far cheaper then
> allocating new objects and working with them via extra indirection.
> It would be almost the same as using Algebraic!(string,Exception,**long,Bulk,MultiBulk)
> from std.variant. Though then you'd miss your nice Type enumeration.
>
>
>
>> I guess that implement the protocol as free functions isn't a bad option
>> because D offers this imperative style and the protocol is so small that
>> doesn't need more a structured approach. Tell me this is wrong!
>>
>>
> It's up to you in any case. Benefits of extra structure won't show up
> until the code is quite large.
>
>
>
>> thanks from a newbie :-)
>> Pedro Lacerda
>>
>
> You are welcome !
>
> --
> Dmitry Olshansky
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20120305/215d9655/attachment.html>


More information about the Digitalmars-d-learn mailing list