asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Function name and format change in the codebase
Date Sat, 15 Oct 2016 17:26:41 GMT
BTW, in the latest/greatest version of the world, where -'s are dying, 
all of the SQL++ materials are there - folks should start using it!  
(You can start with the 101.) Please open issues if you have issues with 
any of the docs, or encounter bugs.  As I helped work on those 
artifacts, I found that queries felt less verbose and a bit more natural 
in SQL++ versus their AQL equivalents.....  I'm thinking that one of the 
main things we should advertise in our first top-level release is the 
newly available SQL++ face.  (Folks should start making mental lists of 
the things we need to remember to mention as being "new" in that release 
- since it's been so long....)


On 10/14/16 10:52 PM, Yingyi Bu wrote:
> +1.
>
> For (1), the eventual goal is to only have underscores.
> Currently it's a transition period -- all docs are based on underscores.
> For new functions, it's good to only support underscores.
> I think that we'll end the life of hyphens after some time.
>
> Best,
> Yingyi
>
> On Fri, Oct 14, 2016 at 6:36 PM, Till Westmann <tillw@apache.org> wrote:
>
>> I think that the answer to both questions is "yes".
>>
>> My 2c,
>> Till
>>
>> On 14 Oct 2016, at 18:04, Taewoo Kim wrote:
>>
>>> Hi All,
>>>
>>> I would like to talk about 1) Function name convention and Format change
>> in
>>> the codebase.
>>>
>>> 1) Function name
>>> When we invent a new function name, would it be better if we avoid using
>>> '-'(dash) in a new function name and use "_" instead to avoid two
>> versions
>>> for the same function in AQL and SQL++?
>>>
>>> 2) Format change in the codebase
>>> When we modify a java source file, is it better to apply format changes
>> to
>>> the whole file or the lines that we only touch? For history perspective,
>> I
>>> think the latter is desirable.
>>>
>>> Best,
>>> Taewoo


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message