Hi,
I added a test to confirm the return type as Stream.
If there are no more comments, will push it tomorrow.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-stream-8146218/
Roger
On 1/28/2016 12:00 AM, Roger Riggs wrote:
Hi Tagir,
After the discussion, I agree.
The only addition I
As with many rules there are cases where one may break them for other
overriding reasons. I think this is one of those cases for
ZipFile/JarFile.stream(), since for many usages the signature of the stream
will not pop out into an explicit type. I have not looked at the specific case
for streams
Hi Tagir,
After the discussion, I agree.
The only addition I would like to see in the tests to add or modify
a test so that the it explicitly requires the Stream at
compile time.
None of the new tests check that the result type signatures are
as expected.
Thanks, Roger
On 1/27/16 11:28 PM,
Hello!
It should be noted that there's already a precedent in JDK where
method returning stream is subclassed and returns the stream of more
concrete objects. I'm speaking about ZipFile and JarFile:
public class ZipFile {
public Stream stream() {...}
}
public class JarFile extends ZipFile {
Hi Stephen, Tagir,
On 1/27/2016 10:30 AM, Stephen Colebourne wrote:
On 27 January 2016 at 15:13, Roger Riggs wrote:
On 1/26/2016 8:57 AM, Stephen Colebourne wrote:
Thus, adding the ChronoLocalDate methods later will make two additional
methods available on LocalDate (as they will not override
On 27 January 2016 at 15:13, Roger Riggs wrote:
> On 1/26/2016 8:57 AM, Stephen Colebourne wrote:
>> Thus, adding the ChronoLocalDate methods later will make two additional
>> methods available on LocalDate (as they will not override).
>
> Since all the calendars are built on the same 24hour days
Hi Stephen,
On 1/26/2016 8:57 AM, Stephen Colebourne wrote:
While there is no blocking reason why the concept could not be pulled up to
ChronoLocalDate, the method signatures would differ.
LocalDate::datesUntil(LocalDate)
LocalDate::datesUntil(LocalDate, Period)
ChronoLocalDate::datesUntil(Chr
While there is no blockng reason why the concept could not be pulled up to
ChronoLocalDate, the method signatures would differ.
LocalDate::datesUntil(LocalDate)
LocalDate::datesUntil(LocalDate, Period)
ChronoLocalDate::datesUntil(ChronoLocalDate)
ChronoLocalDate::datesUntil(ChronoLocalDate, Chron
> On 25 Jan 2016, at 18:47, Xueming Shen wrote:
>
> The proposed change looks fine with me.
>
Yes, +1 nice work.
Paul.
The proposed change looks fine with me.
sherman
On 1/23/16 1:40 PM, Roger Riggs wrote:
Hi,
Looks good.
I would want to verify that it is defined such that if it later needs
to be
abstracted up to ChronoLocalDate and apply to compatible Chronologies
and respective local dates such as Japanes
Hello!
Thanks for sponsoring! If something is still necessary from my side
regarding this issue, feel free to ask.
With best regards,
Tagir Valeev.
RR> Hi,
RR> Looks good.
RR> I would want to verify that it is defined such that if it later needs to be
RR> abstracted up to ChronoLocalDate and a
Hi,
Looks good.
I would want to verify that it is defined such that if it later needs to be
abstracted up to ChronoLocalDate and apply to compatible Chronologies
and respective local dates such as JapaneseDate there is no conflict.
It should not be an issue since Period implements ChronoPeriod.
Hello!
Thank you for review! I did very small change in unit test comments to
make them less confusing. Here's updated webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8146218/r3/
With best regards,
Tagir Valeev.
SC> I'm happy with the logic and specification of this proposal. I think it
SC>
I'm happy with the logic and specification of this proposal. I think it
will be a useful addition.
I'll let the Oracle team chime in to do a further review.
thanks
Stephen
On 16 January 2016 at 13:31, Tagir F. Valeev wrote:
> Hello!
>
> Thanks for review! Here's the updated patch:
> http://c
Hello!
Thanks for review! Here's the updated patch:
http://cr.openjdk.java.net/~tvaleev/webrev/8146218/r2/
SC> The docs say that if the end date is before the start date, the
SC> stream is empty. While I can see just about why LongStream.range()
SC> works that way, I don't think this API should.
Thanks for the patch.
The docs say that if the end date is before the start date, the stream is
empty. While I can see just about why LongStream.range() works that way, I
don't think this API should. The minimum is an exception, but it would be
easy to support negative in the days-only case or the
Hello!
Thank you for your comments. I logged an issue:
https://bugs.openjdk.java.net/browse/JDK-8146218
And prepared a patch:
http://amaembo.github.io/cr/8146218/webrev-1/
(sorry for not using official code-review server, I cannot access it
currently, hopefully this problem will be solved soon).
17 matches
Mail list logo
