From: SourceForge.net <no...@so...> - 2008-09-05 03:45:15
|
Feature Requests item #2094316, was opened at 2008-09-05 03:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Request.filterWith has bizarre behavior Initial Comment: Request.filterWith(Filter) (and filterWith(Description) too?) currently has very bizarre behavior: it returns a NEW Request instance which has the desired filtering behavior. However, the old Request instance is left unaffected. This means that the following code--which everyone is likely to naturally want to write--is actually buggy: Request request = Request.classes(someClass); request.filterWith(someFilter); The correct code, which took me awhile to figure out, is: Request request = Request.classes(someClass); request = request.filterWith(someFilter); If you are going to retain this strange behavior, the javadocs of filterWith need to be modified to explicitly point out this behavior, and show both the buggy and corrent code examples above. But I would recommend that you change the behavior. The best way would be to add Filter or Description options to the Request constructor, so that you could do everything on one line like: Request request = Request.classes(someClass, someFilter); The state of Request could be made final so that it is immutable and multithread safe etc. Baring that, change filterWith(Filter) to NOT return a new Request but to simply modify the instance at hand. Then I think that the method would behave like most programmers expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-11-16 17:52:45
|
Feature Requests item #2094316, was opened at 2008-09-04 23:45 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Request.filterWith has bizarre behavior Initial Comment: Request.filterWith(Filter) (and filterWith(Description) too?) currently has very bizarre behavior: it returns a NEW Request instance which has the desired filtering behavior. However, the old Request instance is left unaffected. This means that the following code--which everyone is likely to naturally want to write--is actually buggy: Request request = Request.classes(someClass); request.filterWith(someFilter); The correct code, which took me awhile to figure out, is: Request request = Request.classes(someClass); request = request.filterWith(someFilter); If you are going to retain this strange behavior, the javadocs of filterWith need to be modified to explicitly point out this behavior, and show both the buggy and corrent code examples above. But I would recommend that you change the behavior. The best way would be to add Filter or Description options to the Request constructor, so that you could do everything on one line like: Request request = Request.classes(someClass, someFilter); The state of Request could be made final so that it is immutable and multithread safe etc. Baring that, change filterWith(Filter) to NOT return a new Request but to simply modify the instance at hand. Then I think that the method would behave like most programmers expect. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:21
|
Feature Requests item #2094316, was opened at 2008-09-05 03:45 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Request.filterWith has bizarre behavior Initial Comment: Request.filterWith(Filter) (and filterWith(Description) too?) currently has very bizarre behavior: it returns a NEW Request instance which has the desired filtering behavior. However, the old Request instance is left unaffected. This means that the following code--which everyone is likely to naturally want to write--is actually buggy: Request request = Request.classes(someClass); request.filterWith(someFilter); The correct code, which took me awhile to figure out, is: Request request = Request.classes(someClass); request = request.filterWith(someFilter); If you are going to retain this strange behavior, the javadocs of filterWith need to be modified to explicitly point out this behavior, and show both the buggy and corrent code examples above. But I would recommend that you change the behavior. The best way would be to add Filter or Description options to the Request constructor, so that you could do everything on one line like: Request request = Request.classes(someClass, someFilter); The state of Request could be made final so that it is immutable and multithread safe etc. Baring that, change filterWith(Filter) to NOT return a new Request but to simply modify the instance at hand. Then I think that the method would behave like most programmers expect. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2094316&group_id=15278 |